On Maandag 07 März 2005 04:13, Albert Cahalan wrote:
> Christoph Hellwig writes:
> > See the review I sent. Write is exactly the right interface for that kind
> > of thing. For comment vs argument either put the number first so we don't
> > have the problem of finding a delinator that isn't a valid filename, or
> > use '\0' as such.
>
> That's just putrid. You've proposed an interface that
> combines the worst of ASCII with the worst of binary.
I guess it's possible to avoid the need for passing the command at all.
The read data already has a format that mixes binary and variable-length
ascii data, so write could use a data structure similar (or even identical)
to the one used there, e.g.
struct inotify_watch_request {
__u32 mask; /* watch mask */
__u32 len; /* length (including nulls) of name */
char name[0]; /* stub for name */
};
This can replace both INOTIFY_WATCH and INOTIFY_IGNORE, if you simply
define a zero mask as a special value for ignore. FIONREAD is a
well-established interface, so I don't think it's necessary to replace
this.
> Adding plain old syscalls is rather nice actually.
> It's only a pain at first, while waiting for glibc
> to catch up.
Yes, that might be a workable interface as well, but don't mix syscalls
with a misc device then. Instead, you might build on something like
futexfs, with syscalls replacing both ioctl and read:
int inotify_open(int flags);
int inotify_watch(int fd, unsigned mask, char *name);
int inotify_ignore(int fd, int wd);
int inotify_getevents(int fd, int max_events, struct inotify_event *);
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
