Re: [PATCH] new system call mknod64

[You prefer sending to l-k only. But my mailbox is [e-mail],
and l-k is read elsewhere. What you send there I may or may not see.
If you want me to see it, please cc.]

>> u64, or, if you prefer, as struct { u32 major, minor; }.

> Any reason why we don't just *make it* a struct?

Well, I have also done that of course. Both struct and u64 work well.
Since only kdev_t.h knows about the actual structure of kdev_t
it is very easy to switch.

--------------
typedef struct {
        u32 major;
        u32 minor;
} kdev_t;

#define major(dev)      ((dev).major)
#define minor(dev)      ((dev).minor)
#define mk_kdev(major, minor)   ((kdev_t) { major, minor } )

#define HASHDEV(dev)    (major(dev) ^ minor(dev))       /* arbitrary */
#define NODEV           (mk_kdev(0,0))
#define kdev_none(dev)  (major(dev) == 0 && minor(dev) == 0)

static inline int kdev_same(kdev_t dev1, kdev_t dev2)
{
        return (dev1.major == dev2.major) && (dev1.minor == dev2.minor);
}
--------------

(there are some defines in the tty code that have to be adapted,
that is all)

>> sys_mknod takes unsigned int (instead of dev_t)
>> sys_mknod64 takes two unsigned ints.

> Why unsigned int?  If we have a legacy call it should presumably use
> the legacy __u16 format.

That would become rather ugly. The present situation is not u16,
it depends on the architecture. But unsigned int covers the
present situation on all architectures.

Andries