Messages in this thread |  | | Date | Wed, 13 Dec 2000 22:29:29 -0500 (EST) | From | Alexander Viro <> | Subject | Re: ANNOUNCE: Linux Kernel ORB: kORBit |
| |
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > > Err... how about this: Give me two or three kORBit syscalls and I can get > > > rid of all the other 100+ syscalls! :) > > > Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity > > of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as > > userland is concerned. int 0x80 on x86. Can't beat that, can you? > > Err shame on you, don't forget about lcall and exceptions, and interrupts, > and... That is technically more than _o_n_e_ "entry point". :) Oh wait, > what about sysenter/exit too? :)
OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest... what the hell does userland to interrupts? <thinks> OK, make it 2 - pagefault can be arguably used in that way.
> No I can't beat that. But if you look at the hack job of a system call > table we have, you can see that there is no _really_ standard way of > passing parameters. Oh sure, most of the time, stuff is passed in > registers. Sometimes we get a pointer to an argument struct. Because of > this wonderful design we get all kinds of stuff like sys_oldumount vs > sys_umount and others...
Check how often anything uses the majority of that stuff...
> > Yes, standard RPC mechanism would be nice. No, CORBA is not a good candidate - > > too baroque and actually known to lead to extremely tasteless APIs being > > implemented over it. Yes, I mean GNOME. So sue me. > > Hrm... because I'm stupid, please explain how CORBA is too baroque... I
Check 9P and compare. Really. Section 5 of Plan 9 manpages. Available on plan-9.bell-labs.com/sys/man/
> have no problem with you not liking GNOME... you're a kernel hacker, so > you're not supposed to like GUI's. :) [just kidding!!!] CORBA doesn't > preclude nasty APIs any more than C does. It also doesn't preclude *nice* > APIs that are upgradable and extensible in the future (and that means > without breaking backwards compatibility). Please don't tell me that OOP > is bad... or else we will have the eviscerate the VFS layer from the > kernel (amount other subsystems)... :)
OOP is a nice tool. However, it's a tool that has incredible potential of shooting one's foot. It's wonderful if you have sane set of methods. And that's a _big_ if. "Easily extensible" is not an absolutely good thing - C++ wankers all over the world are busily proving it every day. Heck, they make a living out of that. IOW, the problem with interface changes is _not_ in converting the old code. It's in choosing the right changes. And that part of the game can't be simplified.
> > I would take 9P over that any day, thank you very much. > > Like I mentioned in a previous email, CORBA does not preclude 9P. What > it does buy you though, is compatibility with LOTS of preexisting CORBA > tools. How much development infrastructure is there for 9P? I thought > so. :)
All UNIX userland on the client side. lib9p on the server side (23Kb of sparse C). Examples of use in servers - see the aforementioned site.
> For one of our demos, we ran a file server on a remote linux box (that we > just had a user account on), mounted it on a kORBit'ized box, and ran > programs on SPARC Solaris that accessed the kORBit'ized linux box's file > syscalls. If nothing else, it's pretty nifty what you can do in little > code...
Duh. And what's new about that?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |