lkml.org 
[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [linux-usb] Re: USB device allocation
In <Pine.GSO.4.10.9910090525450.14121-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:


AV> On Sat, 9 Oct 1999, Khimenko Victor wrote:

>> AV> Learn. This place is not exactly UNIX 101, you know...
>>
>> Yes. I know. I know even more: Linux is NOT Unix.

AV> Yes, it is. Sorry to break it upon you, but..

1. It's NOT certified as Unix.
2. It's NOT derived from Unix sources.

So which way you can call it "Unix" is unclear to me. Unix-like -- all right.
Unix -- no.

>> Why we should borrow each
>> and every idea from Unix without even thinking is beyond me.

AV> Well, if you refuse to think it's your business. I can't help here.

Hmm. I think. Think once more. Directory was text file initially and was
modified by suid mkdir program when needed. It's changed now. Why ? It was
so wonderfull idea ! /dev is not filesystem now but bunch of special files.
Why to have special files and not special filesystem is so wonderfull idea ?

>> I'm not use Unix, I use Linux.

AV> I don't eat meat, I eat beef...

Once more: Linux is not Unix. At least just now. Neither certified as Unix nor
derived from Unix sources...

>> AV> devfs may be good/bad/whatever, but _why_ _the_ _green_ _bloody_
>> AV> _fsck_ is it discussed on l-k by people who apparently never cared to look
>> AV> at the code it should interact with?
>>
>> Just since system created only by kernel hackers without interaction with
>> non-kernel hackers will be usable ONLY for kernel hackers. BTW I seen that
>> code. It's little non-standard usage of VFS but it's real life, not academic
>> research.

AV> One more time. Slowly. Take. Care. To. Look. At. The. Code. That. Is.
AV> Supposed. To. Work. With. Devfs. Look. At. The. VFS. Code.
AV> Sheesh...

You mean that the only reason to reject devfs is troubles with VFS ? Hmm.
For last two years devfs was adopted to changing VFS all right. Or you changed
VFS with devfs in mind ??? Hard to believe. Yes, it uses VFS non-standard way.
Now what ? What planned VFS change will unrepairable break devfs ?

>> AV> It's not a democracy and vox co^H^Hpopuli doesn't work here (or anywhere
>> AV> else, for that matter).
>>
>> It worked with gcc :-) Yes, here problem is not enough to solve it such
>> painfull way, but who knows...

AV> I hate to piss on your parade, but _that_ will definitely take some
AV> reading of the source. It's kinda hard to fork the code without learning
AV> it... Oh, wait. I see. _That_ part of the work you are leaving to Richard
AV> humbly limiting your participation with the PR stuff. Sorry, but you are
AV> doing it poorly.

Yes, this will need a lot of peoples with deep knowleadge of kernel. That's
why it's not happen yet and hardly happens soon (devfs is great thing but not
great enough to justify kernel fork).

>> BTW since most arguments against devfs was NOT
>> technical ones (even from Linus !!!) I can not understood how reading of
>> kernel sources will help here...

AV> Though luck, then. What you are telling boils down to: "I want it; I don't
AV> give a damn for the problems; code around and I can't be even bothered to
AV> figure out what those problems _are_." Do you really expect to be taken
AV> seriously?

Problems are solved by Richard mostly. So far I hear only about one technical
problem with devfs (from you BTW): problems with VFS (which one BTW: rename is
not implemented in procfs and procfs is included in kernel; what's is so
different in devfs?). This is THE ONLY REAL problem. All other problems are
myths or political ones. Is it the only reason to not include devfs in kernel ?
BTW what about devpts and procfs: are they any better from VFS side ? They are
both in kernel and devpts was added when devfs already existed...

>> AV> It is a prerequisite.
>>
>> It's prerequisite ONLY when something is rejected purely on techincal basis.
>> This is not a case with devfs.

AV> No, sir. You will have to deal with the technical reasons. "Purely" has
AV> nothing to this sad fact. BTW, may I also remind you that l-k is a
AV> _technical_ list?

Hmm. Looking on messages published there for last few days you hardly can say
that :-) If the only reasons to not include devfs in kernel are technical ones
then what are they ? If there are some reasons then WHERE should are they be
discussed ? For devfs to be included in kernel ALL reasons should be resolved...

AV> Look, I have no vendetta against devfs. I respect Richard. I _have_
AV> technical problems with devfs as it is implemented. And I have no respect
AV> to the screaming advocates. FWIC they may go and play with themselves, NT
AV> or something equally icky. If I'll get a taste for political bullshit,
AV> well, I know where to find SplashSnort. Could we _PLEASE_ stop this
AV> idiocy? If you want to figure out WTF causes problems with devfs - you are
AV> welcome.

BTW why there are no such summary anywhere ? So you can say: "devfs is great,
but there are problems: 1) ..., 2) ..., 3) ...; go away and return back when
are they are solved -- if they are will be solved devfs will be included in
kernel". So far I've not seen messages from peoples who can say to Linus "now
devfs is ok from subsystem I maintain in Linux kernel and you can take a look
on it". Since devfs touches quite a few subsystems devfs should be adopted to
have "Ok" from some top kernel hackers before Linus will try to look on it.

AV> And that will take some RTFS. Or you can scream and act as a brat
AV> expecting people to do the things they do not want just because _you_ want
AV> it. In that case... well, see above.

There are quite a few things in kernel not welcomed by Linus initially.
But in case with devfs I can not see technical problems at all -- just
political ones. There are problem with rename, for example, but procfs also
has it AFAIK. Why it's Ok for procfs and not Ok for devfs ?




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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:1.840 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site