> Alexander Viro writes:
> > On Sat, 26 Jun 1999, Albert D. Cahalan wrote:
>
> >> NTFS has a 4th time stamp.
> >
> > Fsck, no. Not another OOB channel for whatever random bullshit
> > somebody wants to push through. Not another ioctl() - we have
> > enough mess already.
>
> We could really use something that:
>
> * comes in all the variants (FOO, lFOO, and fFOO)
> * handles misc. junk like ioctl does()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is *not* a good idea.
> * is tidy, unlike ioctl() -- size ought to be a parameter
OK. We might do very neat and tidy scheme *if* we wouldn't have all kinds
of old binaries kicking around. IMO the very neat one would be simply
open2(fd, name) (+ 2 more variants) that would take an fd and name in
hierarchical namespace and return another fd. Such that read() and write()
there would cover the stuff currently done by fcntl(), ioctl(),
{set,get}sockopt(), chmod(), stat(), utimes(), etc. But it would make
sense if we could drop the old syscalls. That could be done in the very
beginning, but not now. Binary compatibility. I like that idea, since it
seriously reduces the API width and has the right sound (everything is
a file), but we can't do it now. David will kill you if you'll try to pull
that trick ;-) Probably it could be done over 5-6 years, though...
The main problem with that would be to keep the namespace clean -
otherwise we'ld simply move clutter there.
> >> HFS has type and creator data.
> >
> > No. Way. In. Hell. It's *not* a support for forks - if you want
>
> Those are simple 32-bit values.
Look - in that case it's purely HFS business, right? OK, my apologies for
tone (ahem) - 'twas YABDayFH. Sorry.
If this stuff is reasonably small - fine, it's can be done.
> So developers are stuck with ioctl() + a new API.
> They have to learn something new, but can't junk the cruft.
>
> >> Oh, be sure to use a 64-bit inode if you return that data.
> >
> > I don't see any place for inumber there.
>
> You started with "new_stat" for a name.
Look downthread. new_stat() was tossed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/