Messages in this thread | | | From | Andries.Brouwer@cwi ... | Date | Tue, 22 Apr 2003 03:02:06 +0200 (MEST) | Subject | Re: [PATCH] new system call mknod64 |
| |
[You prefer sending to l-k only. But my mailbox is aeb@cwi.nl, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |