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

Linus Torvalds
2001-05-20T19:34:30Z

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