Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 9 Oct 1999 15:26:58 +0400 (MSD) | Subject | RE: [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/
| |