LKPI updates for drm-v4.18

[• hselasky]

Summary

Minor additions to the LKPI needed for drm-v4.17

[• hselasky]

sys/compat/linuxkpi/common/include/linux/sched.h

185

Remove this comment

This function is not portable because applications use sizeof(task->comm) to computer the buffer length which is sizeof(void *) in FreeBSD instead of TASK_COMM_LEN !!

I suggest the following implementation:

static inline const char *
get_task_comm(char *buf, struct task_struct *task)
{

        buf[0] = 0; /* buffer is too small */
        return (task->comm);
}

[mmacy]

• respond to feedback
• further changes for 4.18

[bwidawsk]

sys/compat/linuxkpi/common/include/linux/hardirq.h

41 ↗

(On Diff #50901)

I think something like this might almost do the right thing:

void
_intr_drain_filter(int irq)
{
        struct intr_event *ie;
        struct intr_thread *ithd;
        struct thread *td;

        ie = intr_lookup(irq);
        if (ie == NULL)
                return;
        if (ie->filter == NULL)
                return;

        mtx_lock(&ie->ie_lock);
        phase = ie->ie_phase;
        intr_event_barrier(ie);
        atomic_store_rel_int(&ie->ie_phase, phase);
        mtx_unlock(&ie->ie_lock);

        return;
}

sys/compat/linuxkpi/common/include/linux/kernel.h

133 ↗

(On Diff #50901)

Would probably be good to add this to param.h

sys/compat/linuxkpi/common/include/linux/ktime.h

179 ↗

(On Diff #50901)

It doesn't seem like timespec64 will be something else any time soon.

return (timespec_to_ns(ts));

?

sys/compat/linuxkpi/common/include/linux/random.h

51

get_random_int already does this. Maybe just

#define get_random_u32 get_random_int

?

[• hselasky]

sys/compat/linuxkpi/common/include/linux/fs.h

325 ↗

(On Diff #50901)

Please don't use C99 comments. use /* */ instead or remove this comment.

From what I know i_private maps to v_data, but I doubt anyone is setting that, especially for open. You could check who is using it. Keeping the code as is doesn't harm. Try to use BSD style: return (0);

[johalun]

We can abandon this in favor of D19565

[• hselasky]

Is this patch still relevant?

[johalun]

In D18041#440083, @hselasky wrote:

Is this patch still relevant?

No, it can be abandoned (but I don't have permission to do it myself)

[• hselasky]

Already committed or no longer applicable.