Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

[Andries.Brouwer]

    From: Ben LaHaise <bcrl@redhat.com>

    3. Userspace partition code proposal

        Given the above two bits, here's a brief explaination of a
        proposal to move management of the partitioning scheme into
        userspace, along with portions of raid startup, lvm, uuid and
        mount by label code needed for mounting the root filesystem.

        Consider that the device node currently known as /dev/hda5 can
        also be viewed as /dev/hda at offset 512000 with a limit of 10GB.
        With the extensions in fs/block_dev.c, you could replace /dev/hda5
        with /dev/hda/offset=512000,limit=10240000000.  Now, by putting
        the partition parsing code into a libpart and binding mount to a
        libpart, the root filesystem mounting code can be run out of an
        initrd image.  The use of mount gives us the ability to mount
        filesystems by UUID, by label or other exotic schemes without
        having to add any additional code to the kernel.

    I'm going to stop writing this now.  I need sleep...

Hmm. You know that I wrote this long ago?
And that it has been part of the kernel for a long time?
And that there are user space utilities that use it?

In util-linux, look at the partx subdirectory.
In the kernel, read drivers/block/blkpg.c.

Andries

Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

[Andrew Morton]

Andries.Brouwer@cwi.nl wrote:
> 
> Hmm. You know that I wrote this long ago?

Well, let's not get too hung up on the disk thing (yeah,
I started it...).

Ben's intent here is to *demonstrate* how argv-style
info can be passed into device nodes.  It seems neat,
and nice.

We can also make use of a strong argument parsing library
in the kernel - there are a great number of open-coded
string bashing functions which could be rationalised
and regularised.


So.  When am I going to be able to:

	open("/bin/ls,-l,/etc/passwd", O_RDONLY);

?

Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

[Alexander Viro]

On Sat, 19 May 2001, Andrew Morton wrote:

> So.  When am I going to be able to:
> 
> 	open("/bin/ls,-l,/etc/passwd", O_RDONLY);

You are not. Think for a minute and you'll see why.

Linus' idea of /dev/tty/<parameters> is marginally sane - it makes sense
to consider that as configuring-upon-open. You _are_ going to do IO on
that file.

Ben's /dev/md0/<living_horror> is ugly - it's open just for side effects,
with no IO supposed to happen.

His idea of passing file descriptor instead of name makes these side effects
even messier.

The stuff you've proposed is a perversion worth of Albert. You've introduced
additional metacharacter into filenames, you will need some form of quoting
to be able to pass literal commas and you will need to quote slashes. It's
way past ugly.

Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace

[Andrew Morton]

Alexander Viro wrote:
> 
>  It's way past ugly.

I knew you'd like it.

It kind of makes sense, because it puts the two primary stream-of-bytes
objects in Unix into the same namespace, with the same accessors.
So if some random application is expecting a filename well heck, you
just give it a path-to-executable with args.  It won't care, although
it may have trouble lseek()ing on it.

It wasn't very serious at all.

-

Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

[Ben LaHaise]

On Sat, 19 May 2001, Alexander Viro wrote:

> Ben's /dev/md0/<living_horror> is ugly - it's open just for side effects,
> with no IO supposed to happen.

Now that I'm awake and refreshed, yeah, that's awful.  But
echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
the system can even send back result codes that way.

		-ben

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> Now that I'm awake and refreshed, yeah, that's awful.  But
> echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
> the system can even send back result codes that way.

Only to an English speaker. I suspect Quebec City canadians would prefer a
different command set.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sat, 19 May 2001, Alan Cox wrote:

> > Now that I'm awake and refreshed, yeah, that's awful.  But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
> > the system can even send back result codes that way.
> 
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.

Alan, I'm not a native speaker and I had worked with system that got names
of utilities translated to Russian.

It's was hell. And I don't think that replacing compress (or пакуй) with
42A1769 would make it better.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Sat, May 19, 2001 at 05:25:22PM +0100, Alan Cox wrote:
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.

Should we support `pas387' as well as `no387' as a kernel boot parameter
then?  Face it, a sysadmin has to know the limited subset of english
which is used to configure a kernel.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Nicolas Pitre]

On Sat, 19 May 2001, Alan Cox wrote:

> > Now that I'm awake and refreshed, yeah, that's awful.  But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
> > the system can even send back result codes that way.
>
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.

Well...  Around here we've been used to Microsoft translations like:

ETES-VOUS CERTAIN [O/N] ?

... and of course pressing 'o' doesn't work while 'y' does.  :-)

Wanting to localize such low-level keywords is utopia.  Otherwise you'll
want to translate command names like free, rm, mv, etc. and yet programming
languages as well like C keywords.  And then you come to a point where
nothing could be interoperable any more.


Nicolas

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sat, 19 May 2001, Alan Cox wrote:
>
> > Now that I'm awake and refreshed, yeah, that's awful.  But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
> > the system can even send back result codes that way.
> 
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.

I was waiting for the "anglo-saxon" argument.

I don't think it's a valid argument. You already have "/dev". You already
have english names for the numbers in ioctl's (and let's not be mentally
dishonest and say "numbers are cross-cultural", because NOBODY MUST EVER
USE THE RAW NUMBERS - you have to use the anglo-saxon #define'd names
because the numbers aren't even cross-platform on Linux, much less
portable to other systems).

So the "English is bad" argument is a complete non-argument.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Ingo Oeser]

On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote:
[Reasons]
> So the "English is bad" argument is a complete non-argument.

Jepp, I have to agree. 

English is used more or less as an communication protocol in
computer science and for operating computers.

Once you know how to operate an computer in English, you can
operate nearly every computer in the world, because they have
English as default locale.

Let's not repeat Babel please :-(

PS: English is neither mine, nor Linus native language. Why do
   the English natives complain instead of us? ;-)

<off topic side note>
   And be glad that's not German, that has this role. English
   sentences are WAY easier to parse by computers, because it
   doesn't use much suffixes and prefixes on words and has very
   few exceptions. Also these exceptions are eleminated from
   command languages WITHOUT influencing readability and
   comprehensability.
</off topic side note>


Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Ingo Oeser wrote:

> PS: English is neither mine, nor Linus native language. Why do
>    the English natives complain instead of us? ;-)

Because we had some experience with, erm, localized systems and for
Alan it's most likely pure theory? ;-)

				Al, still shuddering at the memories

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> On Sun, 20 May 2001, Ingo Oeser wrote:
> > PS: English is neither mine, nor Linus native language. Why do
> >    the English natives complain instead of us? ;-)
> 
> Because we had some experience with, erm, localized systems and for
> Alan it's most likely pure theory? ;-)

I think its important its considered. I do like the idea of a sensible ioctl
encoding (including ascii potentially) and being able to ship ioctls over the
network. 

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Padraig Brady]

Obviously there has to be some standard base
with which to work, especially for computer language
keywords as these can't be converted due to name
clashes. What would be cool is to pick a better base
language than English that everyone would have to
learn to "use computers". This is especially important
for opensource as it would greatly ease the operation
of the collective brain. Something easily parseable
would be an obvious criterion and would allow us
to interact with computers by voice(-recognition)
with no ambiguity, etc. etc...
tada: http://www.lojban.org/

will everything be changed over in the 2.5 timeframe? :-)

Padraig.

Ingo Oeser wrote:

>On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote:
>[Reasons]
>
>>So the "English is bad" argument is a complete non-argument.
>>
>
>Jepp, I have to agree. 
>
>English is used more or less as an communication protocol in
>computer science and for operating computers.
>
>Once you know how to operate an computer in English, you can
>operate nearly every computer in the world, because they have
>English as default locale.
>
>Let's not repeat Babel please :-(
>
>PS: English is neither mine, nor Linus native language. Why do
>   the English natives complain instead of us? ;-)
>
><off topic side note>
>   And be glad that's not German, that has this role. English
>   sentences are WAY easier to parse by computers, because it
>   doesn't use much suffixes and prefixes on words and has very
>   few exceptions. Also these exceptions are eleminated from
>   command languages WITHOUT influencing readability and
>   comprehensability.
></off topic side note>
>
>
>Regards
>
>Ingo Oeser
>

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Pavel Machek]

Hi!

> > Now that I'm awake and refreshed, yeah, that's awful.  But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane.  Heck,
> > the system can even send back result codes that way.
> 
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.

Alan, bad idea.

This is less evil than magic numbers, and *users* should not be
touching this anyway. They should have nice gui tools that do it for
them.

English is *way* better than magic numbers. It makes sense at least
for someone.
								    Pavel 

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

[Alexander Viro]

On Sat, 19 May 2001, Andrew Clausen wrote:

> Alexander Viro wrote:
> > On Sat, 19 May 2001, Andrew Clausen wrote:
> > 
> > > (1) these issues are independent.  The partition parsing could
> > > be done in user space, today, by blkpg, if I read the code correctly
> > > ;-)  (there's an ioctl for [un]registering partitions)  Never
> > > tried it though ;-)
> > 
> > ioctls are even more evil than encoding limits into the name.
> 
> Why?  Encoding sounds funky... you don't get normal
> ls behaviour, etc.

ioctls are evil, period. At least with these names you can use normal
scripting and don't need any special tools. Every ioctl means a binary
that has no business to exist.

> What about partition editing on other OSs?  There's no reason
> why fdisk/parted/etc. should be Linux only.  Why should the kernel
> need to know how to write partition tables?

It needs to read them. Writing doesn't add much. I'd rather see
trivial partitioning tools that consist only of UI code in case
of Linux.

> Also, different partition table formats have different alignment
> constraints (which is relevant for creating partitions).  These
> mainly need to be respected for other braindead OS's and/or BIOSes.
> 
> Communicating those between user/kernel space doesn't excite me.

So don't communicate them.
 
> Libtool & friends deals with version skew (ugly, but it works...)

With statically linked binaries? How?
 
> You can write wrappers for libraries.

Uh-huh. And you can write them for ioctls. We had been busily doing that
for years. Results are not pretty, to put it very mildly.

OK, let me put it that way: I know how to do it in the kernel with
no code duplication and less impact on userland. BTW, most of the
code can very well sit in the userland, but that's another story
(userland filesystems). Anyway, there's only one way to settle such
stuff - sit down and write the patch. Which is what I'm going to do.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> ioctls are evil, period. At least with these names you can use normal
> scripting and don't need any special tools. Every ioctl means a binary
> that has no business to exist.

That is not IMHO a rational argument. It isn't my fault that your shell does
not support ioctls usefully. If you used perl as your login shell you would
have no problem there.

Alan

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Erik Mouw]

On Sat, May 19, 2001 at 03:02:47PM +0100, Alan Cox wrote:
> > ioctls are evil, period. At least with these names you can use normal
> > scripting and don't need any special tools. Every ioctl means a binary
> > that has no business to exist.
> 
> That is not IMHO a rational argument. It isn't my fault that your shell does
> not support ioctls usefully. If you used perl as your login shell you would
> have no problem there.

Sure, you're right, but Al's point is that you shouldn't need to.

One of the fundamentals of Unix is that "everything is a file" and that
you can do everything by reading or writing that file. The devices are
the big exception, they need ioctls to control them. With Al's proposal
we can get rid of the ioctls and let the devices behave like normal
files.


Erik
[who remembers a discussion like this years ago on comp.os.linux.kernel
 with similar conclusion: ioctls are bad, we should get rid of them]

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Aaron Lehmann]

On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote:
> One of the fundamentals of Unix is that "everything is a file" and that
> you can do everything by reading or writing that file.

But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
if it's there. writing to files that aren't shown in directory listings
is plain evil. I really don't want to explain why. It's extremely
messy and unintuitive.

It would be better to do this with a file that does exist, for example
writing something to /proc/disks/sda/arguments. Then again, I don't
even think much of dynamic file systems in the first place.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Erik Mouw]

On Sat, May 19, 2001 at 10:45:11AM -0700, Aaron Lehmann wrote:
> On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote:
> > One of the fundamentals of Unix is that "everything is a file" and that
> > you can do everything by reading or writing that file.
> 
> But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
> if it's there. writing to files that aren't shown in directory listings
> is plain evil. I really don't want to explain why. It's extremely
> messy and unintuitive.
> 
> It would be better to do this with a file that does exist, for example
> writing something to /proc/disks/sda/arguments. Then again, I don't
> even think much of dynamic file systems in the first place.

A network socket also isn't a file in a filesystem, you can't do ls on
it, it doesn't even exist until you create one, but still you use it as
a file by reading and writing it. I don't see any difference in the way
you create /dev/sda/offset=234234,limit=626737537 by just using it.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Steven Walter]

On Sat, May 19, 2001 at 09:38:03PM +0200, Erik Mouw wrote:
> > But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
> > if it's there. writing to files that aren't shown in directory listings
> > is plain evil. I really don't want to explain why. It's extremely
> > messy and unintuitive.
> > 
> > It would be better to do this with a file that does exist, for example
> > writing something to /proc/disks/sda/arguments. Then again, I don't
> > even think much of dynamic file systems in the first place.
> 
> A network socket also isn't a file in a filesystem, you can't do ls on
> it, it doesn't even exist until you create one, but still you use it as
> a file by reading and writing it. I don't see any difference in the way
> you create /dev/sda/offset=234234,limit=626737537 by just using it.

I think you're kind of missing the point.  Erik is saying that, by the
path, it appears to be a file, even though it isn't listed as a file in
the directory /dev/sda.  Network sockets don't have a path, unless its a
Unix domain socket, and then you /can/ 'ls' it.

My opinion is that putting options directly in the open is no nicer than
an ioctl.  I think that where this scheme really shines, though, is
where there are multiple logical channels to a device, as in the
/dev/fb0/control example.  I like that.  What could be done, therefore,
is have a /dev/ttyS0/control file, where you could "echo
'baud=19200,parity=odd' > /dev/ttyS0/control" or even "echo '19200' >
/dev/ttyS0/baud" and "echo 'odd' > /dev/ttyS0/parity".  That seems to me
to be the cleanest and most logical solution.

As for this partition stuff, it seems a bad example to me.  Maybe I'm
just spoiled, but I think partitions is something that the kernel can
and should abstract.  None of this /dev/sda/offset=12345,limit=45678
madness.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Richard Gooch]

Alan Cox writes:
> > ioctls are evil, period. At least with these names you can use normal
> > scripting and don't need any special tools. Every ioctl means a binary
> > that has no business to exist.
> 
> That is not IMHO a rational argument. It isn't my fault that your
> shell does not support ioctls usefully. If you used perl as your
> login shell you would have no problem there.

There is another reason to use ioctl(2): when you need to send data to
the kernel/driver and wait for a response. It supports transactions,
which read(2) and write(2) cannot. Therefore it remains useful.

Al, if you really want to kill ioctl(2), then perhaps you should
implement a transaction(2) syscall. Something like:
    int transaction (int fd, void *rbuf, size_t rlen,
		     void *wbuf, size_t wlen);

Of course, there wouldn't be any practical gain, since we already have
ioctl(2). Any gain would be aesthetic.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
> Al, if you really want to kill ioctl(2), then perhaps you should
> implement a transaction(2) syscall. Something like:
>     int transaction (int fd, void *rbuf, size_t rlen,
> 		     void *wbuf, size_t wlen);
> 
> Of course, there wouldn't be any practical gain, since we already have
> ioctl(2). Any gain would be aesthetic.

I can tell you haven't had to write any 32-bit ioctl emulation code for
a 64-bit kernel recently.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Richard Gooch]

Matthew Wilcox writes:
> On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
> > Al, if you really want to kill ioctl(2), then perhaps you should
> > implement a transaction(2) syscall. Something like:
> >     int transaction (int fd, void *rbuf, size_t rlen,
> > 		     void *wbuf, size_t wlen);
> > 
> > Of course, there wouldn't be any practical gain, since we already have
> > ioctl(2). Any gain would be aesthetic.
> 
> I can tell you haven't had to write any 32-bit ioctl emulation code for
> a 64-bit kernel recently.

The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect. People can pass pointers to ill-designed structures very
easily. The main advantage of transaction(2) is that hopefully, people
will not be so bone-headed as to forget to pass sizeof *structptr
as the size field. So perhaps some error trapping is possible.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> The transaction(2) syscall can be just as easily abused as ioctl(2) in
> this respect.

But read() and write() cannot.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Richard Gooch]

Matthew Wilcox writes:
> On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > this respect.
> 
> But read() and write() cannot.

Sure they can. I can pass a pointer to a structure to either of them.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sat, 19 May 2001, Richard Gooch wrote:
>
> Matthew Wilcox writes:
> > On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> > > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > > this respect.
> > 
> > But read() and write() cannot.
> 
> Sure they can. I can pass a pointer to a structure to either of them.

You're missing the point.

It's ok to do "read()/write()" on structures. In fact, people do that all
the time (and then they complain about the file not being portable ;)

The problem with ioctl is that not only are people passing ioctl's
pointers to structures, but:
 - they're not telling how big the structure is
 - the structure can have pointers to other places
 - sometimes it modifies the structure passed in

None of which are "network-nice". Basically, ioctl() is historically used
as a "pass any crap into driver xxxx, and the driver - and ONLY the driver
- will know what to do with it".

And when _only_ a driver knows what the arguments mean, upper layers can't
encapsulate them. Upper layers cannot make a packet of the argument and
send it over the network to another machine. Upper layers cannot do
sanity-checking on things like "is this argument a valid pointer". Which
means, for example, that not only can you not send the ioctl arguments
anywhere, but ioctl's have also historically been a hot-bed of bugs.

Example traditional ioctl bugs: use kernel pointers to access the argument
(because it just happens to work on x86, never mind the fact that if the
argument is bad you'll get a kernel oops and/or a serious security error).
Other example: different drivers/f ilesystems implementing the same ioctl,
but disagreeing on what the argument means (is it a pointer to an integer
argument, or the integer itself?).

Now, the advantage of using read()/write() is (a) that it's unambiguous
where the argument comes from and how big it is and (b) because of that
the _psychology_ is different. You don't get into this "pass random crap
around, let the kernel modify user data structures directly" mentality.

And psychology is important.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Russell King]

On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
> You're missing the point.

I don't think Richard is actually.  I think Richard has hit a nail
dead on its head.

> It's ok to do "read()/write()" on structures.

Ok, we can read()/write() structures.  So someone invents the following
structure:

	struct foo {
		int cmd;
		void *data;
	} foo;

Now they use write(fd, &foo, sizeof(foo)); Haven't they just swapped
the ioctl() interface for write() instead?

Ok, lets hope that humanity isn't that stupid, so lets take another
example:

	struct bar {
		int in_size;
		void *in_data;
		int out_size;
		void *out_data;
	};

	struct foo {
		int cmd;
		struct bar1;
	} foo;

Same write call, but ok, we have a structure of known size.  Its still
the same problem.

What I'm trying to say is that I think that read+write is open to more
or the same abuse that ioctl has been, not less.

However, it does have one good thing going for it - you can support
poll on blocking "ioctls" like TIOCMIWAIT.

> None of which are "network-nice". Basically, ioctl() is historically used
> as a "pass any crap into driver xxxx, and the driver - and ONLY the driver
> - will know what to do with it".

I still see read()/write() being a "pass any crap" interface.  The
implementer of the target for read()/write() will probably still be
a driver which will need to decode what its given, whether its in
ASCII or binary.

And driver writers are already used to writing ioctl-like interfaces.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Russell King wrote:

> I still see read()/write() being a "pass any crap" interface.  The
> implementer of the target for read()/write() will probably still be
> a driver which will need to decode what its given, whether its in
> ASCII or binary.
> 
> And driver writers are already used to writing ioctl-like interfaces.

You _are_ missing the point. write() doesn't have that history of wild
abuse. It's easier to whack the driver writer's balls for abusing it.
I'm more than willing to play Narn Bat Squad and I'm pretty sure that
I'm not alone at that.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sun, 20 May 2001, Russell King wrote:
>
> On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
> > You're missing the point.
> 
> I don't think Richard is actually.  I think Richard has hit a nail
> dead on its head.
> 
> > It's ok to do "read()/write()" on structures.
> 
> Ok, we can read()/write() structures.  So someone invents the following
> structure:
> 
> 	struct foo {
> 		int cmd;
> 		void *data;
> 	} foo;
> 
> Now they use write(fd, &foo, sizeof(foo)); Haven't they just swapped
> the ioctl() interface for write() instead?

Wrong.

Nobody will expect the above to work, and everybody will agree that the
above is a BUG if the read() call will actually follow the pointer.

Read my email. And read the last line: "psychology is important".

Step #1 in programming: understand people.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Russell King]

On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote:
> Nobody will expect the above to work, and everybody will agree that the
> above is a BUG if the read() call will actually follow the pointer.

I didn't say anything about read().  I said write().  Obviously it
wouldn't work for read()!

> Read my email. And read the last line: "psychology is important".

I did.  I also know that if you give the world enough rope, someone
will hang themselves.

(Note that because I've thought a way of misusing this in the same
was as ioctl, you can bet your bottom dollar that other people will).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sun, 20 May 2001, Russell King wrote:
>
> On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote:
> > Nobody will expect the above to work, and everybody will agree that the
> > above is a BUG if the read() call will actually follow the pointer.
> 
> I didn't say anything about read().  I said write().  Obviously it
> wouldn't work for read()!

No, but the point is, everybody _would_ consider it a bug if a
low-level driver "write()" did anything but touched the explicit buffer.

Code like that would not pass through anybody's yuck-o-meter. People would
point fingers and say "That is not a legal write() function". Anybody who
tried to make write() follow pointers would be laughed at as a stupid git.

Anybody who makes "ioctl()" do the same is just following years of
standard practice, and the yuck-o-meter doesn't even register.

THAT is the importance of psychology.

Technology is meaningless. What matters is how people _think_ of it.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Linus Torvalds wrote:

> No, but the point is, everybody _would_ consider it a bug if a
> low-level driver "write()" did anything but touched the explicit buffer.
> 
> Code like that would not pass through anybody's yuck-o-meter. People would
> point fingers and say "That is not a legal write() function". Anybody who
> tried to make write() follow pointers would be laughed at as a stupid git.

Linus, as much as I'd like to agree with you, you are hopeless optimist.
90% of drivers contain code written by stupid gits.
 
> Anybody who makes "ioctl()" do the same is just following years of
> standard practice, and the yuck-o-meter doesn't even register.

Nobody reads the drivers. Because otherwise yuck-o-meters would go off-scale.

How about yuck value of the
	* removing a file by writing "-1" into it?
	* mkdir() populating directory.
	* unlink() not working in said directory.
	* rmdir() happily removing it. And freeing all associated structures.
Opened files? What opened files? Whaddya mean, "oops"?

How about sprintf(s + strlen(s), foo)?

How about a collection of b0rken strtoul() implementations? Including one
that contains
	switch (...) {
		case 48:
		case 49:
	(all 22 cases)

How about declaring global array and comparing it with NULL?

How about the whole binfmt_misc.c?

Ehh...

Linus, I've been doing exactly that (reading through the large parts of
tree) and trust me, yuck-o-meter was off-scale almost permanently. Level
of idiocy in the obvious bugs is such that I bet you anything that code
had never been really read through by anyone who knew C.

I would love it if more people actually cared to read the fscking code.
Too few are doing that.

And yes, it's a psychological problem, not a technical one. Oh, well...

Sorry about the rant - I've just spent a couple of hours wading through
the piles of excrements in drivers/*. Ouch.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> Linus, as much as I'd like to agree with you, you are hopeless optimist.
> 90% of drivers contain code written by stupid gits.

I think thats a very arrogant and very mistaken view of the problem. 90%
of the driver are written by people who are

	-	Copying from other drivers
	-	Using the existing API's to make their job easy
	-	Working to timescales
	-	Just want it to work

So if you take ioctl away from them they will implement ioctl emulation by
writing ioctl structs to an fd.

If you want to make these things work well you have to provide a good working
infrastructure. You don't change anything (except the maintainer) by causing
pain. Instead you provide the mechanisms - the generic parsing code so that
people don't screw up on procfs parsing - the generic ioctl alternatives etc.

Ditto with the major numbers. You win that battle by getting enough people to
believe it is the right answer that they write the nice code for managing 
resources and naming assignment - which is already beginning to occur. Then
even if I'm still maintaining a major number list in 2 years nobody can quite
remember why, and people are heard murmering 'You should have tried Linux two
years ago, you had to actually make device files yourself sometimes'

Alan

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Alan Cox wrote:

> > Linus, as much as I'd like to agree with you, you are hopeless optimist.
> > 90% of drivers contain code written by stupid gits.
                   ^^^^^^^
> 
> I think thats a very arrogant and very mistaken view of the problem. 90%
> of the driver are written by people who are

written by != contain code written by. Stuff initally written by sane
people tends to get all sorts of crap into it. Unfortunately.

The problem being: very few people actually read the code in drivers/*.
And crap accumulates. The messier it is, the faster it gets shitted.

So relying on the people finding crappy ->write() instances and ridiculing
the authors in public is... well, somewhat naive. There's more than enough
crap already and that simply doesn't happen. It _can_ be done, but it will
take more than just having the code sitting there.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Paul Fulghum]

>> 90% of drivers contain code written by stupid gits.
>
> From: "Alan Cox"
> I think thats a very arrogant and very mistaken view of the problem. 90%
> of the driver are written by people who are
> 
> - Copying from other drivers
> - Using the existing API's to make their job easy
> - Working to timescales
> - Just want it to work

I'll be the first to admit there is some ugliness in my driver.

Some originates from accepted methods when the
driver originated. (points 1 and 2 above)

Some comes from doing new things with only the
existing infrastructure, because changing the infrastructure
is deemed too intrusive. (points 3 and 4 above)
Stable infrastructure is good, but sometimes ugliness results.

Some is the result of genuine mistakes (people who
have written nothing but perfect code flame away).
I fix these as they are found through use and review,
and the code improves. (I *really do* want my driver to work!)

As new facilities and guidelines are made available,
I *gladly* and *gratefully* use them, and the code improves.

Calling driver writers stupid and devising punitive measures
to 'cause them pain' seems less useful.

Paul Fulghum paulkf@microgate.com
Microgate Corporation http://www.microgate.com

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Paul Fulghum wrote:

> I'll be the first to admit there is some ugliness in my driver.

So will anyone here regarding his or her code. Count me in, BTW.

Could you reread the posting you are refering to?

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Paul Fulghum]

From: "Alexander Viro" <viro@math.psu.edu>
> On Sun, 20 May 2001, Paul Fulghum wrote:
> > I'll be the first to admit there is some ugliness in my driver.
>
> So will anyone here regarding his or her code. Count me in, BTW.
>
> Could you reread the posting you are refering to?

Sorry if I misunderstood. My post was as much in
response to several current threads revolving around
device major numbers and ioctl calls (I use both!).

Many postings seem to imply driver writers must be flawed for
using these flawed facilities. Driver writers don't use device
major numbers and ioctl calls because they are brain damaged, they use
them because they are accepted practice and they work (albeit imperfectly).

I have no problem moving to better solutions *as they become available*.

But I have seen multiple references to 'causing pain' for people
by restricting their use while alternatives  (only now being discussed
and decided) are years away in the next stable kernel.

All I hope for  is a reasonable path to get there (better alternatives) from
here.
My 2 cents, with no intent to offend anyone.

Paul Fulghum paulkf@microgate.com
Microgate Corporation http://www.microgate.com

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> How about sprintf(s + strlen(s), foo)?

Solar Designer said two years ago we should be using snprintf in the kernel.
He was most decidedly right 8)

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Ingo Molnar]

On Sun, 20 May 2001, Alexander Viro wrote:

> Linus, as much as I'd like to agree with you, you are hopeless
> optimist. 90% of drivers contain code written by stupid gits.

90% of drivers contain code written by people who do driver development in
their spare time, with limited resources, most of the time serving as a
learning excercise. And they do this freely and for fun. Accusing them of
being 'stupid gits' is just micharacterising the situation. People do not
get born as VFS hackers, there is a very steep learning curve, and only a
few make it to to have knowledge like you. Much of the learning curve of
various people has traces in drivers/*, it's more like the history of
Linux then some coherent image of people's capabilities.

	Ingo

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Mon, 21 May 2001, Ingo Molnar wrote:

> 
> On Sun, 20 May 2001, Alexander Viro wrote:
> 
> > Linus, as much as I'd like to agree with you, you are hopeless
> > optimist. 90% of drivers contain code written by stupid gits.
> 
> 90% of drivers contain code written by people who do driver development in
> their spare time, with limited resources, most of the time serving as a
> learning excercise. And they do this freely and for fun. Accusing them of

Probably 100% of drivers contains code from more than one author.

> being 'stupid gits' is just micharacterising the situation. People do not
> get born as VFS hackers, there is a very steep learning curve, and only a
> few make it to to have knowledge like you. Much of the learning curve of
> various people has traces in drivers/*, it's more like the history of
> Linux then some coherent image of people's capabilities.

Grrr... Ingo, could you read what I said? I'm not talking about problems
coming from lack of knowledge about the kernel. I'm not saying that authors
of drivers are stupid gits (in the cases when they in all probability are
such they are usually anonymous - FUBAR Acme Inc. is all you see). I'm
not saying that 90% of code in drivers is crap.

What I am saying is that in a lot of drivers you can find a code that
is result of plain and simple lack of knowledge about basics of C. And I mean
the basics, not the nontrivial parts.

"Oh, look, I don't know C, here's that project, let's write something and
submit the patch" looks pretty stupid to me.

I'm not talking about bugs. I'm not talking about stupid interfaces.
I'm not talking about typos. I'm not talking about people doing strlen()
on arrays that came from unverified source. I'm talking about the code
that was obviously written by somebody who considers C as voodoo.

The things Linus refered to pale on that background. On the bogosity
scale we have a lot of code that is way higher. Since it manages to
stay unnoticed for years...

And no, I don't think that it's an arrogance. BTW, I don't know who
the authors of these pieces are. I know that problems they had could
be cured by reading any book on C (K&R, Bolsky, whatever) and considering
how long some of that stuff had been in the tree... Well, doesn't speak
highly of the intellect of those who'd written it.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Mon, 21 May 2001, Ingo Molnar wrote:
> 
> On Sun, 20 May 2001, Alexander Viro wrote:
> 
> > Linus, as much as I'd like to agree with you, you are hopeless
> > optimist. 90% of drivers contain code written by stupid gits.
> 
> 90% of drivers contain code written by people who do driver development in
> their spare time, with limited resources, most of the time serving as a
> learning excercise. And they do this freely and for fun. Accusing them of
> being 'stupid gits' is just micharacterising the situation.

I would disagree with both of you.

The problem is not whether people do it with limited resources or time, or
whether they are stupid or not.

The problem is that if you expect to get nice code, you have to have nice
interfaces and infratructure. And ioctl's aren't it.

The reason we _can_ write beautiful filesystems these days is that the VFS
layer _supports_ it. In fact, the VFS layer has tons of infrastructure and
structure that makes it _hard_ to write bad filesystem code (which is not
to say that we don't have ugly code there - but much of it is due to
historically not having had quite the same level of infrastructure).

If we had nice infrastructure to make ioctl's more palatable, we could
probably make do even with the current binary-number interfaces, simply
because people would use the infrastructure without ever even _seeing_ how
lacking the user-level accesses are.

But that absolutely _requires_ that the driver writers should never see
the silly "pass a random number and a random argument type" kind of
interface with no structure or infrastructure in place.

Because right now even _good_ programmers make a mess of the fact that
they get passed a bad interface.

Think of it this way: the user interface to opening a file is
"open()" with pathnames and magic flags. But a filesystem never even
_sees_ that interface, it sees a very nicely structured setup where all
the argument parsing and locking has already been done for it, and the
magic flags don't even exist any more as far as the low-level FS is
concerned. Which is why filesystems _can_ be clean.

In contrast, ioctl's are passed through directly, with no help to make
them clean. 

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 20.05.01 in <Pine.LNX.4.21.0105202005070.8426-100000@penguin.transmeta.com>:

> If we had nice infrastructure to make ioctl's more palatable, we could
> probably make do even with the current binary-number interfaces, simply
> because people would use the infrastructure without ever even _seeing_ how
> lacking the user-level accesses are.
>
> But that absolutely _requires_ that the driver writers should never see
> the silly "pass a random number and a random argument type" kind of
> interface with no structure or infrastructure in place.

Hmm.

So would it be worthwile to invent some infrastructure - possibly  
including macros, possibly even including a (very small) code generator, I  
don't really have any details clear at this point - that allows you to  
specify an interface in a sane way (for example, but not necessarily, as a  
C function definition, though that may be too hard to parse), and have the  
infrastructure generate

1. some code to call ioctl() with these arguments
2. some other code to pick apart the ioctl buffer and call the actual
   function with these arguments

preferrably so that (a) the code from 1 is suitable for use in libc or  
similar places, (b) the code from 2 is suitable for the kernel, (c) most  
(all would be better but may not be practical) existing ioctls could be  
described that way?

(If so, the first task would obviously be to analyze existing code in  
those places, and the actual structure of existing ioctls, to find out  
what sort of stuff needs to be supported, before trying to design the  
mechanism to support it.)

A variant possibility (that I suspect you'll like significantly less)  
would be a data structure to describe the ioctl that gets interpreted at  
runtime. I think I prefer specific code for that job. At least *some*  
ioctls are in hot spots, and interpreting is slow. And that hypothetical  
encapsulation certainly should not know the difference between fast and  
slow interrupts^Wioctls.

MfG Kai

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Albert D. Cahalan]

Linus Torvalds writes:

> The problem is that if you expect to get nice code, you have to have nice
> interfaces and infratructure. And ioctl's aren't it.
...
> But that absolutely _requires_ that the driver writers should never see
> the silly "pass a random number and a random argument type" kind of
> interface with no structure or infrastructure in place.
>
> Because right now even _good_ programmers make a mess of the fact that
> they get passed a bad interface.
>
> Think of it this way: the user interface to opening a file is
> "open()" with pathnames and magic flags. But a filesystem never even
> _sees_ that interface, it sees a very nicely structured setup where all
> the argument parsing and locking has already been done for it, and the
> magic flags don't even exist any more as far as the low-level FS is
> concerned. Which is why filesystems _can_ be clean.
>
> In contrast, ioctl's are passed through directly, with no help to make
> them clean.

You want a well-defined interface, allowing over-network use?
Well, here you go, the CORBA ORB patch for Linux 2.4 kernels:
http://korbit.sourceforge.net/

Do you want that against 2.4.5-pre5 or what? Plain ASCII email?

:-)

The really sick thing is that I could actually use this too.
It handles the DSP problem well.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sat, 19 May 2001, Richard Gooch wrote:

> The transaction(2) syscall can be just as easily abused as ioctl(2) in
> this respect. People can pass pointers to ill-designed structures very

Right. Moreover, it's not needed. The same functionality can be trivially
implemented by write() and read(). As the matter of fact, had been done
in userland context for decades. Go and buy Stevens. Read it. Then come
back.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Sat, 19 May 2001, Richard Gooch wrote:
> 
> > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > this respect. People can pass pointers to ill-designed structures very
> 
> Right. Moreover, it's not needed. The same functionality can be
> trivially implemented by write() and read(). As the matter of fact,
> had been done in userland context for decades. Go and buy
> Stevens. Read it. Then come back.

I don't need to read it. Don't be insulting. Sure, you *can* use a
write(2)/read(2) cycle. But that's two syscalls compared to one with
ioctl(2) or transaction(2). That can matter to some applications.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Pavel Machek]

Hi!

> > > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > > this respect. People can pass pointers to ill-designed structures very
> > 
> > Right. Moreover, it's not needed. The same functionality can be
> > trivially implemented by write() and read(). As the matter of fact,
> > had been done in userland context for decades. Go and buy
> > Stevens. Read it. Then come back.
> 
> I don't need to read it. Don't be insulting. Sure, you *can* use a
> write(2)/read(2) cycle. But that's two syscalls compared to one with
> ioctl(2) or transaction(2). That can matter to some applications.

I just don't think so. Where did you see performance-critical use of
ioctl()?
							       Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> > I don't need to read it. Don't be insulting. Sure, you *can* use a
> > write(2)/read(2) cycle. But that's two syscalls compared to one with
> > ioctl(2) or transaction(2). That can matter to some applications.
> 
> I just don't think so. Where did you see performance-critical use of
> ioctl()?

AGP, video4linux,...

Alan

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Mon, 21 May 2001, Alan Cox wrote:

> > > I don't need to read it. Don't be insulting. Sure, you *can* use a
> > > write(2)/read(2) cycle. But that's two syscalls compared to one with
> > > ioctl(2) or transaction(2). That can matter to some applications.
> > 
> > I just don't think so. Where did you see performance-critical use of
> > ioctl()?
> 
> AGP, video4linux,...

Which, BTW, is a wonderful reason for having multiple channels. Instead
of write(fd, "critical_command", 8); read(fd,....); you read from the right fd.
Opened before you enter the hotspot. Less overhead than ioctl() would
have...

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> Which, BTW, is a wonderful reason for having multiple channels. Instead
> of write(fd, "critical_command", 8); read(fd,....); you read from the right fd.
> Opened before you enter the hotspot. Less overhead than ioctl() would
> have...

The ioctl is one syscall, the read/write pair are two. Im not sure that ioctl
is going to be more overhead there. In the video4linux case the high overhead
is acking frames received by mmap so might conceivably be considered one way

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Mon, 21 May 2001, Alan Cox wrote:

> > Which, BTW, is a wonderful reason for having multiple channels. Instead
> > of write(fd, "critical_command", 8); read(fd,....); you read from the right fd.
> > Opened before you enter the hotspot. Less overhead than ioctl() would
> > have...
> 
> The ioctl is one syscall, the read/write pair are two. Im not sure that ioctl
> is going to be more overhead there. In the video4linux case the high overhead
> is acking frames received by mmap so might conceivably be considered one way

Sure. But we have to do two syscalls only if ioctl has both in- and out-
arguments that way. Moreover, we are talking about non-trivial in- arguments.
How many of these are in hotspots?

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> Sure. But we have to do two syscalls only if ioctl has both in- and out-
> arguments that way. Moreover, we are talking about non-trivial in- arguments.
> How many of these are in hotspots?

There is also a second question. How do you ensure the read is for the right 
data when you are sharing a file handle with another thread..

ioctl() has the nice property that an in/out ioctl is implicitly synchronized

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Mon, 21 May 2001, Alan Cox wrote:
>
> > Sure. But we have to do two syscalls only if ioctl has both in- and out-
> > arguments that way. Moreover, we are talking about non-trivial in- arguments.
> > How many of these are in hotspots?
>
> There is also a second question. How do you ensure the read is for the right
> data when you are sharing a file handle with another thread..
>
> ioctl() has the nice property that an in/out ioctl is implicitly synchronized

I don't think we can generically replace ioctl's with read-write, and we
shouldn't bend over backwards even _trying_.

The important thing would be to give them more structure, and as far as
I'm personally concerned I don't even care if the user-level access method
ends up being the same old thing. After all, we have magic numbers
everywhere: even a system call uses magic numbers for the syscall entry
numbering. The thing that makes system call numbers nice is that the
number gets turned into a more structured thing with proper type checking
and well-defined semantics very very early on indeed.

It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
yes. No question about it. But we don't necessarily have to redesign the
whole approach - we only want to re-design the internal kernel interfaces.

That, in turn, might be as simple as changing the ioctl incoming arguments
of <cmd,arg> into a structure like <type,cmd,inbuf,inlen,outbuf,outlen>.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Mon, 21 May 2001, Linus Torvalds wrote:

> It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> yes. No question about it. But we don't necessarily have to redesign the
> whole approach - we only want to re-design the internal kernel interfaces.
> 
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of <cmd,arg> into a structure like <type,cmd,inbuf,inlen,outbuf,outlen>.

drivers/net/ppp_generic.c:
ppp_set_compress(struct ppp *ppp, unsigned long arg)
{
        int err;
        struct compressor *cp;
        struct ppp_option_data data;
        void *state;
        unsigned char ccp_option[CCP_MAX_OPTION_LENGTH];
#ifdef CONFIG_KMOD
        char modname[32];
#endif

        err = -EFAULT;
        if (copy_from_user(&data, (void *) arg, sizeof(data))
            || (data.length <= CCP_MAX_OPTION_LENGTH
                && copy_from_user(ccp_option, data.ptr, data.length)))
                goto out;

And that's far from being uncommon. They _do_ follow pointers. Some - more
than once.

We _will_ have to support ioctls for long. No questions about that. And
there is no magic trick that would work for all of them, simply because
many are too disgusting to be left alive. Let's clean the groups that can
be cleaned and see what's left.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Paul Mackerras]

Alexander Viro writes:

> drivers/net/ppp_generic.c:
> ppp_set_compress(struct ppp *ppp, unsigned long arg)
> {
[snip]
>         if (copy_from_user(&data, (void *) arg, sizeof(data))
>             || (data.length <= CCP_MAX_OPTION_LENGTH
>                 && copy_from_user(ccp_option, data.ptr, data.length)))
>                 goto out;
> 
> And that's far from being uncommon. They _do_ follow pointers. Some - more
> than once.

:) That particular example is one that would probably be much cleaner
as a write on a control fd.  What is there currently is just a
relatively ugly way of getting a variable-sized lump of data from
usermode into the kernel.

Paul.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Oliver Xymoron]

On Mon, 21 May 2001, Alexander Viro wrote:

> On Mon, 21 May 2001, Linus Torvalds wrote:
>
> > It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> > yes. No question about it. But we don't necessarily have to redesign the
> > whole approach - we only want to re-design the internal kernel interfaces.
> >
> > That, in turn, might be as simple as changing the ioctl incoming arguments
> > of <cmd,arg> into a structure like <type,cmd,inbuf,inlen,outbuf,outlen>.
>
> drivers/net/ppp_generic.c:
>
> And that's far from being uncommon. They _do_ follow pointers. Some - more
> than once.

Doesn't matter. If we make doing it right substantially easier than doing
it wrong, then people will quit doing it wrong. And it'll be much easier
to spot the ugly hacks in patches.

I actually wrote the above a while back.. lessee.. where's that thread..

http://mlarchive.ima.com/linux-kernel/1999/Jan/4932.html

The end result was using the resource trees to hold pointers to functions
with prototypes like the above (plus file handle info). No more giant
grotty switch statements (though you could keep those if you wanted - just
point all your ioctls to the same old function). Why trees? To implement
inheritance of ioctls through the device hierarchy.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Jan Harkes]

On Mon, May 21, 2001 at 03:10:32PM -0700, Linus Torvalds wrote:
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of <cmd,arg> into a structure like <type,cmd,inbuf,inlen,outbuf,outlen>.

At least make sure that the 'kioctl' returns the number of bytes placed
into the output buffer, as userspace doesn't necessarily know how much
data would be returned. Coda's kernel module forwards control data up to
userspace and uses a reasonably messy 'pioctl' wrapper (also used by AFS
afaik) around an ioctl to inform the kernel module of how much data to
copy through.

something like,

    ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen,
		   void *outbuf, size_t outlen);

As far as functionality and errors it works like read/write in a single
call, pretty much what Richard proposed earlier with a new 'transaction'
syscall. Maybe type is not needed, and cmd can be part of the inbuf in
which case it would be identical. I guess that type is introduced to
resolve existing ioctl number collisions.

Jan

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Tue, 22 May 2001, Jan Harkes wrote:
> 
> something like,
> 
>     ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen,
> 		   void *outbuf, size_t outlen);
> 
> As far as functionality and errors it works like read/write in a single
> call, pretty much what Richard proposed earlier with a new 'transaction'
> syscall. Maybe type is not needed, and cmd can be part of the inbuf in
> which case it would be identical.

I'd rather have type and cmd there, simply because right now the
"cmd" passed in to the ioctl is not well-defined, as several different
drivers use the same numbers for different things (which is why I want to
expand that to <type,cmd> to get uniqueness).

Also, I think the cmd is separate from the data, so I don't think it
necessarily makes sense to mix the two. Even if we want to have an ASCII
command, I'd think that should be separate from the arguments, ie we'd
have 

	ssize_t kioctl(int fd, const char *cmd, const void *inbuf ...

instead of trying to mix them. This is especially true as the
"inbuf" would be a user-mode pointer, while "cmd" would come from kernel
space (whether in the form of a <type,subcmd> number pair or as a kernel
string).

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Ingo Oeser]

On Mon, May 21, 2001 at 05:51:08PM -0400, Alexander Viro wrote:
> Sure. But we have to do two syscalls only if ioctl has both in- and out-
> arguments that way. Moreover, we are talking about non-trivial in- arguments.
> How many of these are in hotspots?

ioctl has actually 4 semantics:

command only
command + read
command + write
command + rw-transaction

Separating these would be a first step. And yes, I consider each
of them useful.

command only: reset drive
command + rw-transaction: "dear device please mangle this data"
   (crypto processors come to mind...)

The other two are obviously needed and already accepted by all of
you.

Hotspots: crypto hardware or generally DSPs.


Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote:
> ioctl has actually 4 semantics:
> 
> command only
> command + read
> command + write
> command + rw-transaction
> 
> Separating these would be a first step. And yes, I consider each
> of them useful.
> 
> command only: reset drive

echo 'reset' >/dev/sg0ctl

> command + rw-transaction: "dear device please mangle this data"
>    (crypto processors come to mind...)

I can't think of a reasonable tool-based approach to this, but I can
definitely see that a program could use this well.  It simply requires
that you use the filp to store your state.

fd = open(/dev/crypto) -> creates filp
write(fd, "Death to all fanatics!\n"); -> calls crypto device, stores result in
	private data structure
sleep(100);
read(fd, "Qrngu gb nyy snangvpf!\n"); -> frees data structure

[You'll note the advanced design of my crypto processor.]

Clearly, this is open to abuse by persons never calling read() and passing in
far too much to write().  I think this can be alleviated by refusing to accept more than (say) 4k at a time, or bean-counter.

A sick way would be to allow the ->write() call to have its buffer
modified.  But I don't think we want to go down that path.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Tue, 22 May 2001, Matthew Wilcox wrote:
>
> > command + rw-transaction: "dear device please mangle this data"
> >    (crypto processors come to mind...)
>
> I can't think of a reasonable tool-based approach to this, but I can
> definitely see that a program could use this well.  It simply requires
> that you use the filp to store your state.

Nope. You can (and people do, quite often) share filps. So you can't
associate state with it.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote:
> Nope. You can (and people do, quite often) share filps. So you can't
> associate state with it.

For _devices_, though?  I don't expect my mouse to work if gpm and xfree
both try to consume device events from the same filp.  Heck, it doesn't
even work when they try to consume events from the same inode :-)  I think
this is a reasonable restriction for the class of devices in question.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> For _devices_, though?  I don't expect my mouse to work if gpm and xfree
> both try to consume device events from the same filp.  Heck, it doesn't
> even work when they try to consume events from the same inode :-)  I think
> this is a reasonable restriction for the class of devices in question.

Not really. Think about basic things like full duplex audio with two threads

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote:
> > For _devices_, though?  I don't expect my mouse to work if gpm and xfree
> > both try to consume device events from the same filp.  Heck, it doesn't
> > even work when they try to consume events from the same inode :-)  I think
> > this is a reasonable restriction for the class of devices in question.
> 
> Not really. Think about basic things like full duplex audio with two threads

`the class of devices in question' was cryptographic devices, and possibly
other transactional DSPs.  I don't consider audio to be transactional.
in any case, you can do transactional things with two threads, as long
as they each have their own fd on the device.  Think of the fd as your
transaction handle.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> `the class of devices in question' was cryptographic devices, and possibly
> other transactional DSPs.  I don't consider audio to be transactional.
> in any case, you can do transactional things with two threads, as long
> as they each have their own fd on the device.  Think of the fd as your
> transaction handle.

Thats a bit pathetic. So I have to fill my app with expensive pthread locks
or hack all the drivers and totally change the multi-open sematics in the ABI

I think I'll stick to ioctl cleaned up

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
> > `the class of devices in question' was cryptographic devices, and possibly
> > other transactional DSPs.  I don't consider audio to be transactional.
> > in any case, you can do transactional things with two threads, as long
> > as they each have their own fd on the device.  Think of the fd as your
> > transaction handle.
> 
> Thats a bit pathetic. So I have to fill my app with expensive pthread locks
> or hack all the drivers and totally change the multi-open sematics in the ABI

huh?

void thread_init(void) {
	int fd = open("/dev/crypto");
	real_thread_init(fd);
}

where was that lock again?

and notice this idea is only for transactional things -- what
transactional things do sound drivers do?

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alan Cox]

> > Thats a bit pathetic. So I have to fill my app with expensive pthread locks
> > or hack all the drivers and totally change the multi-open sematics in the ABI
> huh?

For the sound. And remember each open of /dev/audio is a different channel
potentially (ie its a factory)

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sat, 19 May 2001, Richard Gooch wrote:

> There is another reason to use ioctl(2): when you need to send data to
> the kernel/driver and wait for a response. It supports transactions,
> which read(2) and write(2) cannot. Therefore it remains useful.

Somebody, run to database vendors and tell them that they were selling
snake oil all that time - Richard had just shown that support of remote
transactions is impossible. Can't do that with read() and write(),
dontcha know?

Richard, I hate to break it on you, but
	fd = open(foo, 2);
		/* kernel creates a new struct file, as usual */
	write(fd, data, len);
		/* kernel starts the operation */
	read(fd, reply, size);
		/* we block */
		/* operation is completed */
		/* kernel passes reply to user and wakes it up */
_is_ a support of transactions. And yes, we can trivially distinguish
between requests from different sources - struct file * passed to
->write() is more than enough for that. Moreover, we can easily block
other writers until the action is completed.

Please, get a bloody clue. There are reasons for and against ioctls, but
need to send data and wait for responce is _NOT_ one of them.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[David Woodhouse]

matthew@wil.cx said:
>  I can tell you haven't had to write any 32-bit ioctl emulation code
> for a 64-bit kernel recently.

If that had been done right the first time, you wouldn't have had to either.
For that matter, it's often the case that if the ioctl had been done right
the first time, nobody would have had to fix it up for any architecture.

I made the mistake of using machine-specific types in some ioctls, but 
fixed them as soon as I realised some poor sod was going to have to write 
and maintain the ugly conversion code.

For pointers, sometimes it's justified. Often however, as in my case, it
was just stupidity on the part of the original coder and should be fixed.
Although I suppose I have the advantage that I don't have to worry too much
about binary compatibility for the things I changed.

--
dwmw2

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sun, 20 May 2001, David Woodhouse wrote:
> 
> If that had been done right the first time, you wouldn't have had to either.
> For that matter, it's often the case that if the ioctl had been done right
> the first time, nobody would have had to fix it up for any architecture.

The problem with ioctl's is, let me repeat, not technology.

It's people.

ioctl's are a way to do ugly things. That's what they have ALWAYS been.
And because of that, people don't care about following the rules - if
ioctl's followed the rules, they wouldn't _be_ ioctls in the first place,
but instead have a good interface (say, read()/write()).

Basically, ioctl's will _never_ be done right, because of the way people
think about them. They are a back door. They are by design typeless and
without rules. They are, in fact, the Microsoft of UNIX.

The only way to fix ioctl's is to force people to think about them in
another way. Because if you don't, there is always going to be another
driver writer who adds his own ioctl because it's the easy way to do
whatever he wants without giving it a second of _design_ thought.

Now, a good way to force the issue may be to just remove the "ioctl"
function pointer from the file operations structure altogether. We don't
have to force peopel to use "read/write" - we can just make it clear that
ioctl's _have_ to be wrapped, and that the only ioctl's that are
acceptable are the ones that are well-designed enough to be wrappable. So
we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would
also be able to do all the stuff that is currently done by pretty much
every single architecture out there (ie emulation of ioctl's for different
native modes).

It would probably not be that horrible. Many ioctl's are probably not all
that much used by any real programs any more. The most common ones by far
are the tty ones - and the truly generic ones like "FIONREAD" that it
actually would make sense to generalize more.

Catching stuff like EJECT at a higher layer and turning THOSE kinds of
things into real block device operations would clean up drivers and make
them more uniform.

Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
that make the ugliness explicit and possibly easier to try to manage and
fix? Very probably. And it would mean that driver writers could not just
say "fuck design, I'm going to do this my own really ugly way". 

			Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Linus Torvalds wrote:

> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We don't
> have to force peopel to use "read/write" - we can just make it clear that
> ioctl's _have_ to be wrapped, and that the only ioctl's that are
> acceptable are the ones that are well-designed enough to be wrappable. So
> we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would
> also be able to do all the stuff that is currently done by pretty much
> every single architecture out there (ie emulation of ioctl's for different
> native modes).

Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?

> It would probably not be that horrible. Many ioctl's are probably not all
> that much used by any real programs any more. The most common ones by far
> are the tty ones - and the truly generic ones like "FIONREAD" that it
> actually would make sense to generalize more.

Networking stuff. It _is_ used.
 
> Catching stuff like EJECT at a higher layer and turning THOSE kinds of
> things into real block device operations would clean up drivers and make
> them more uniform.
> 
> Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
> that make the ugliness explicit and possibly easier to try to manage and
> fix? Very probably. And it would mean that driver writers could not just
> say "fuck design, I'm going to do this my own really ugly way". 

How about moratorium on new ioctls in the meanwhile? Whatever we do in
fs/ioctl.c, it _will_ take time.
								Al

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Matthew Wilcox]

On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?

No.

$ ls -l arch/*/kernel/ioctl32*.c
-rw-r--r--    1 willy    willy       22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
-rw-r--r--    1 willy    willy      109475 May 18 16:39 arch/parisc/kernel/ioctl32.c
-rw-r--r--    1 willy    willy      117605 Feb  1 20:35 arch/sparc64/kernel/ioctl32.c

only about 100k.

-- 
Revolutions do not require corporate support.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Matthew Wilcox wrote:

> On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
> 
> No.
> 
> $ ls -l arch/*/kernel/ioctl32*.c
> -rw-r--r--    1 willy    willy       22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
> -rw-r--r--    1 willy    willy      109475 May 18 16:39 arch/parisc/kernel/ioctl32.c
> -rw-r--r--    1 willy    willy      117605 Feb  1 20:35 arch/sparc64/kernel/ioctl32.c
> 
> only about 100k.

You are missing all x86-only drivers.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sun, 20 May 2001, Alexander Viro wrote:
> 
> On Sun, 20 May 2001, Matthew Wilcox wrote:
> 
> > On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> > > Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
> > 
> > No.
> > 
> > $ ls -l arch/*/kernel/ioctl32*.c
> > -rw-r--r--    1 willy    willy       22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
> > -rw-r--r--    1 willy    willy      109475 May 18 16:39 arch/parisc/kernel/ioctl32.c
> > -rw-r--r--    1 willy    willy      117605 Feb  1 20:35 arch/sparc64/kernel/ioctl32.c
> > 
> > only about 100k.
> 
> You are missing all x86-only drivers.

Now, the point is that it _is_ doable, and by doing it in one standard
place (instead of letting each architecture fight it on its own) we'd
expose the problem better, and maybe get rid of some of those
architecture-specific ones.

For example, right now the fact that part of the work _has_ been done by
things like Sparc64 has not actually had any advantages: the sparc64 work
has not allowed people to say "let's try to merge this work", because it
has not been globally relevant, and a sparc64-only file has not been a
single point of contact that could be used to clean up things.

In contrast, a generic file has the possibility of creating new VFS or
device-level interfaces. You can catch block device ioctl's and turn them
into proper block device requests - and send them down the right request
queue. Suddenly a block device driver doesn't just get READ/WRITE
requests, it gets EJECT/SERIALIZE requests too. Without having to add
magic ioctl's that are specific to just one device driver. 

So by having a common point of access, you can actually encourage _fixing_
some of the problems. Historically, sparc64 etc have not been able to do
that - they can only try to convert different ioctl's into another format
and then re-submitting it..

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

On Sun, 20 May 2001, Alexander Viro wrote:
> 
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?

I agree. But it would certainly force people to think about this. And it
may turn out that a lot of it can be streamlined, and not that much ends
up being used very much.

It would also allow a single place of catching the generic ones, and as
such be a place to try to make things like the network ioctl's more
regular: setting things like network device duplex with _real_ interfaces
instead of hiding it in ioctl routines.

Also, note that many ioctl's actually do have fairly regular meaning, and
that it _is_ possible to catch a number of them with those regular
things:

	switch (_IOC_TYPE(number)) {
	case 'x':
		xfs_ioctl(..);

and actually try to enforce the things that Documentation/ioctl-number.txt
tries to document. And make the clashes _explicit_ and thus make people
have more incentive to really try to fix it.

> How about moratorium on new ioctls in the meanwhile? Whatever we do in
> fs/ioctl.c, it _will_ take time.

Ehh.. Telling people "don't do that" simply doesn't work. Not if they can
do it easily anyway. Things really don't get fixed unless people have a
certain pain-level to induce it to get fixed.

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Alexander Viro]

On Sun, 20 May 2001, Linus Torvalds wrote:

> > How about moratorium on new ioctls in the meanwhile? Whatever we do in
> > fs/ioctl.c, it _will_ take time.
> 
> Ehh.. Telling people "don't do that" simply doesn't work. Not if they can
> do it easily anyway. Things really don't get fixed unless people have a
> certain pain-level to induce it to get fixed.

Umm... How about the following:  you hit delete on patches that introduce
new ioctls, I help to provide required level of pain.  Deal?

BTW, -pre4 got new bunch of ioctls. On procfs, no less.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Linus Torvalds]

Davem, check the last thing, please.

On Sun, 20 May 2001, Alexander Viro wrote:
> 
> On Sun, 20 May 2001, Linus Torvalds wrote:
> 
> > > How about moratorium on new ioctls in the meanwhile? Whatever we do in
> > > fs/ioctl.c, it _will_ take time.
> > 
> > Ehh.. Telling people "don't do that" simply doesn't work. Not if they can
> > do it easily anyway. Things really don't get fixed unless people have a
> > certain pain-level to induce it to get fixed.
> 
> Umm... How about the following:  you hit delete on patches that introduce
> new ioctls, I help to provide required level of pain.  Deal?

It still doesn't work.

That only makes people complain about my fascist tendencies. See the
thread about device numbers, where Alan just says "ok, I'll do it without
Linus then". 

The whole point of open source is that I don't have that kind of power. I
can only guide, but the most powerful guide is by guiding the _design_,
not micro-managing.

> BTW, -pre4 got new bunch of ioctls. On procfs, no less.

I know. David has zero taste. 

Davem, why didn't you just make new entries in /proc/bus/pci and let
people do "mmap(/proc/bus/pci/xxxx/mem)" instead of having idiotic ioctl's
to set "this is a IO handle" and "this is a MEM handle"? This particular
braindamage is not too late to fix..

		Linus

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[David Woodhouse]

torvalds@transmeta.com said:
> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We
> don't have to force peopel to use "read/write" - we can just make it
> clear that ioctl's _have_ to be wrapped, and that the only ioctl's
> that are acceptable are the ones that are well-designed enough to be
> wrappable. So we'd have a "linux/fs/ioctl.c" that would do all the
> wrapping,

I have so far resisted adding an 'ioctl' method to the MTD structure. Yet
because userspace needs to be able to request an erase, request information
about the erasesize of the device, etc., I've got an ioctl wrapper much as
you describe in drivers/mtd/mtdchar.c. It calls _real_ functions like 
->erase() in the underlying MTD device, which can't easily be exposed to
userspace (unless we do something silly like using CORBA :)

I can see the advantage of doing what you suggest - add methods to the
struct block_device for the sensible things like HDIO_GETGEO, BLKGETSIZE,
etc. (and anyone suggesting that it's sensible to have the physical block
device driver at all involved in BLKRRPART shall be summarily shot).

But please don't _actually_ put all the ioctl wrappers in fs/ioctl.c. It'd 
be a nightmare for the maintainers of the various sections of it. 

Besides, what on earth does it have to do with file systems?

Maybe abi/ioctl/{blkdev,mtd,usb,scsi,...}.c ?

Having it outside the directories which are traditionally owned by the 
respective subsystem maintainers means that it's far easier to be fascist 
about what's added, too.

On a related note - I was actually beginning to consider a dev-private ioctl
for MTD devices, actually for reasons of taste - some stuff like turning 
on/off the automatic hardware ECC on the DiskOnChip devices I consider ugly
enough that I didn't want to deal with it in generic code. At least a
dev-private ioctl seemed like it would banish the ugliness into the
offending driver, and be vaguely reusable if any other device turned out to
require such ugliness.

--
dwmw2

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Ingo Oeser]

On Sun, May 20, 2001 at 12:02:35PM -0700, Linus Torvalds wrote:
> The problem with ioctl's is, let me repeat, not technology.
> 
> It's people.
> 
> ioctl's are a way to do ugly things. That's what they have ALWAYS been.
> And because of that, people don't care about following the rules - if
> ioctl's followed the rules, they wouldn't _be_ ioctls in the first place,
> but instead have a good interface (say, read()/write()).
> 
> Basically, ioctl's will _never_ be done right, because of the way people
> think about them. They are a back door. They are by design typeless and
> without rules. They are, in fact, the Microsoft of UNIX.
 
Yes, they are. Why? Because we cannot fit all behavior of a
devices _cleanly_ into read/write/mmap/lseek.

If we do, we would need different device views (which implies
aliasing of devices, which HPA does not like) and it would
still be not that clean, because reading from readonly gives a
stream and writing gives a stream too, not particular order
required until now.

[good points]

> Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
> that make the ugliness explicit and possibly easier to try to manage and
> fix? Very probably. And it would mean that driver writers could not just
> say "fuck design, I'm going to do this my own really ugly way". 

Ok, then I give you an real world example where I idly fight with
design since nearly 2 years.

A free programmable DSP (or set of DSPs) with several kinds of
memory and additional optional devices (like DAC/ADC, ISDN frames
and sth. like that) on it. This DSP is attached via some glue
logic on Parallel port, PCI, ISA or (soon to come) USB.

This thingie can (once programmed) act as a data sink, data
source or data processing pipe.

OTOH it should be randomly accessable via debuggers and program
loaders. It is also resettable/rebootable, has discontinous
memory of certain kinds (possibly harvard architecture) and many
more funny stuff. And it needs to upload software.

I try to unify all these stuff into a "Generic Processing Device
Layer" for Linux.

Now I like to be shown how I should fit this into clean design
that:

   - uses NO ioctls (Linus)
   - has only one device per DSP (H.P.A)
   - Does not emulate ioctls via read/write transactions (which I
     consider bogus)

Theory is nice, but until someone can show me a clean design for
this (admittedly heavy ;-)) example, I just don't buy your
arguments. 

A *better* ioctl would be nice, but we still need an "catch all
exceptional accesses" interface, IMNSHO.


Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.