lkml.org 
[lkml]   [2003]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.332 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site