linux-kernel - Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Jun 2009 13:09:01 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
cc:	Andreas Dilger <adilger@....com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-afs@...ts.infradead.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

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()?

Yes.

> > 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.

No.

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...

Why?

So far, you're just spouting total nonsense.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/