Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s
From: Linus Torvalds
Date: Wed Jun 17 2009 - 16:09:54 EST
On Wed, 17 Jun 2009, David Howells wrote:
> > But if you do that new system call, then what's the point again? You're
> > back to pinfo() anyway.
> Ummm... pinfo()? Did you mean pioctl()?
> > No. It's because it's another _typeless_ multiplexor.
> What do you mean by 'typeless'? Even the master syscall mux is typeless,
> depending on how you look at it; either that, or it's the superposition of a
> multiplicity of types selected by an arbitrary number.
No, it's not typeless, and you're just an ugly troll.
The master syscall mutex is VERY WELL DEFINED, and doesn't change randomly
depending on what file you happen to look at. It's also somethign where
people actually spend time and effort before adding new entries, instead
of the incessant cluster-fuck that is always the random ioctl, where
subsystems add a new entry at the drop of a hat.
> Short of doing something like an XML or ASN1 structured interface, we aren't
> going to get that, and do we really want to go down that path?
> The difference between the syscall mux and a filesystem's ioctl/pioctl mux is
> that the both need to check on their arguments.
What kind of idiotic "arguments" are these. Neither of them is in the
least true, relevant, or anything sane at all.
Why should I bother reading any further, when you show that your emails
are full of pointless crap?
> > - learn from your mistake, and not do another f*cking disaster that just
> > takes a pathname instead of a fd. Do something else, that actually has
> > semantics and has a well-defined input and output buffer.
> That sounds like you want all the pioctl functions promoted to syscalls.
It means that I want more structure. Stop making these things up.
More structure to make _guarantees_ that you will never need a compat
layer, for example. More structure so that people can _figure out_ what
the supported set of interfaces are, since they are going to differ for
different files. More structure so that we can see security issues without
having to know every f*cking new entry in that table. Etc etc etc.
> > And guess which one "pioctl()" is. Just take a wild stab at it.
> Well, I'd say it's more intelligent that open+ioctl...
So far, you're just spouting total nonsense.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/