es or uses these wrappers... all
of our modifications to the Linux kernel are contained within the
linux/net/korbit subdirectory.
This is currently implemented with a 2.4.0test10 kernel, although forward
porting should be very easy. This project was implemented as a cs423
semester project by Chr
On Sat, 9 Dec 2000, Mohammad A. Haque wrote:
It was just an example. Basically, you'd be able to do in with just
about any language that has ORBit bindings.
Ben Ford wrote:
Why would you *ever* want to write a device driver in perl???
Precisely... but also, there could be a case where
Don't worry about kORBit. Like most open source projects, it will simply
die out after a while, because people don't find it interesting and there
is really no place for it. If it becomes useful, mature, and refined,
however, it could be a very powerful tool for a large class of
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.
I do have one sensible question. Given that corba is while flexible a
relatively expensive encoding system, wouldn't it be better to keep corba
out of kernel space and talk something which is a simple and cleaner encoding
p9fs exists. I didn't see these patches since August, but
/me trims down CC list...
Local? Funny. It lives atop of TCP or IL quite fine. What's
even funnier, I can use it to export /proc from CPU server to workstation
and use _that_ for remote debugging. Ditto for window system. Ditto for
DNS. Ditto for plumber. No, not on Linux...
No not
either. Oops, wasn't interoperability an important part of the Linux
kernel design? Didn't we want to use and follow and define _real_
standards?
Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
it exists for other *BSD too - never checked that.
Okay, so there
plan-9.bell-labs.com/sys/man/
Arrgh. s/plan-9/plan9/. My apologies.
Cool, thanks, will read. :)
IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams
of characters") representation on the client side and very light-weight
library on the server side. It looks
Okay, so there are _stubs_ for these platforms. How many languages are
there bindings for?
Grr... Let's define the terms, OK? What is available: kernel code that
represents the client side of RPC as a filesystem. Userland clients do
not know (or care) about the mechanisms involved.
But
OK, now I'm completely confused.
* which complex data structures do you want to export from the kernel
in non-opaque way?
* which of those structures are guaranteed to remain unchanged?
* if you have userland-to-userland RPC in mind - why put anything
NO. You want leagacy program to "just get" rounded ints, and new programs
to get the "full precision" of the floating point #'s.
What rounded ints? Rounded to zero? To nearest integer? To plus or minus
infinity? Does program have something to say here?
The exact same thing that older
1. kORBit adds about 150k of code to the 2.4t10 kernel.
2. kNFS adds about 100k of code to the 2.4t10 kernel.
So can you implement a kNFS server in kORBit that takes
less than 50kB of RAM? Otherwise it's still a contributor
to bloat and this argument won't work ;)
Actually the kORBitNFS
There is a large perception of CORBA being slow, but for the most part
it is unjustified.
Well, I've measured using function calls through ORBit is 300 times
slower than using dynamic loading.
...
Which gives me the dl is about 333 times faster than ORBit.
You leave so many details
that is not transparently hidden to the user. Why can't I just open
/dev/net0 and get the first network device? Because we have so many
inconsistent, poorly design, inextensible interfaces laying around, thats
why.
This is a bad example, but a (perhaps?) good point. It seems it should
There is a large perception of CORBA being slow, but for the most part it
is unjustified. I believe that the act of _designing_ a completely new
CORBA is slow compared to some of the other solutions. The question I was
trying to ask is whether you should put something smaller and faster
Of course. Which is why CORBA is about putting STRUCTURE in that stream
of random bytes coming over the wire. Why should I have to rewrite my
marshalling and demarshalling code every time I want to write a
server. read and write are fine. But sometimes I want a
structure.
There is a large perception of CORBA being slow, but for the most part it
is unjustified.
Really? I have that same perception but I can't claim that I've measured it.
On the other hand, I have measured the overhead of straight UDP, TCP, and
Sun RPC ping/pong tests and you can find
Oh, great. So we don't have to care about formatting changes. We just
have to care about the data changes. IOW, we are shielded from the
results of changes that should never happen in the first place. And the
benefit being...?
What the hell are you talking about? Did you even
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
cat /mnt/www/www.kernel.org/index.html
can you do ls /mnt/www/www.kernel.org/ as well? I'm interested, I came
to conclusion that web filesystem is not possible... (If you can't do
Yes, if the server supports webDAV or something similar.
listings, it is not really filesystem; you could
On Thu, 5 Jul 2007, Al Viro wrote:
On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote:
Note that gcc rules for __attribute__() (and that's the only source
of rules we _have_ for the damn thing) clearly say that
int __user *p;
is the same thing as
int *__user p;
sees or uses these wrappers... all
of our modifications to the Linux kernel are contained within the
linux/net/korbit subdirectory.
This is currently implemented with a 2.4.0test10 kernel, although forward
porting should be very easy. This project was implemented as a cs423
semester project by Chris Lat
On Sat, 9 Dec 2000, Mohammad A. Haque wrote:
> It was just an example. Basically, you'd be able to do in with just
> about any language that has ORBit bindings.
>
> Ben Ford wrote:
> > Why would you *ever* want to write a device driver in perl???
>
Precisely... but also, there could be a
> > > It was just an example. Basically, you'd be able to do in with just
> > > about any language that has ORBit bindings.
> Agree. I remember a big complaint about Windows was the huge APIs,
> compared with Unix' tiny list of syscalls. And then I saw the GNOME
> docs... ew!
Err... how
> > Don't worry about kORBit. Like most open source projects, it will simply
> > die out after a while, because people don't find it interesting and there
> > is really no place for it. If it becomes useful, mature, and refined,
> > however, it could be a very powerful tool for a large class
> > 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
> > I do have one sensible question. Given that corba is while flexible a
> > relatively expensive encoding system, wouldn't it be better to keep corba
> > out of kernel space and talk something which is a simple and cleaner encoding
> p9fs exists. I didn't see these patches since August, but
/me trims down CC list...
> Local? Funny. It lives atop of TCP or IL quite fine. What's
> even funnier, I can use it to export /proc from CPU server to workstation
> and use _that_ for remote debugging. Ditto for window system. Ditto for
> DNS. Ditto for plumber. No, not on Linux...
No
> > 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
> > either. Oops, wasn't interoperability an important part of the Linux
> > kernel design? Didn't we want to use and follow and define _real_
> > standards?
> Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
> it exists for other *BSD too - never checked that.
Okay, so
> > > plan-9.bell-labs.com/sys/man/
> Arrgh. s/plan-9/plan9/. My apologies.
Cool, thanks, will read. :)
> IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams
> of characters") representation on the client side and very light-weight
> library on the server side. It
> > Okay, so there are _stubs_ for these platforms. How many languages are
> > there bindings for?
> Grr... Let's define the terms, OK? What is available: kernel code that
> represents the client side of RPC as a filesystem. Userland clients do
> not know (or care) about the mechanisms
> OK, now I'm completely confused.
> * which complex data structures do you want to export from the kernel
> in non-opaque way?
> * which of those structures are guaranteed to remain unchanged?
> * if you have userland-to-userland RPC in mind - why put anything
>
I think that I addressed most if not all of this email in my previous
one... let me know if I missed something.
-Chris
btw, thanks for putting up with me, I know I can be obstinate
sometimes. :)
On Wed, 13 Dec 2000, Alexander Viro wrote:
>
>
> On Wed, 13 Dec 2000, Chris Latt
> > NO. You want leagacy program to "just get" rounded ints, and new programs
> > to get the "full precision" of the floating point #'s.
> What rounded ints? Rounded to zero? To nearest integer? To plus or minus
> infinity? Does program have something to say here?
The exact same thing that
> > 1. kORBit adds about 150k of code to the 2.4t10 kernel.
> > 2. kNFS adds about 100k of code to the 2.4t10 kernel.
> So can you implement a kNFS server in kORBit that takes
> less than 50kB of RAM? Otherwise it's still a contributor
> to bloat and this argument won't work ;)
Actually the
>> There is a large perception of CORBA being slow, but for the most part
>> it is unjustified.
> Well, I've measured using function calls through ORBit is 300 times
> slower than using dynamic loading.
> ...
> Which gives me the dl is about 333 times faster than ORBit.
You leave so many
> >that is not transparently hidden to the user. Why can't I just open
> >/dev/net0 and get the first network device? Because we have so many
> >inconsistent, poorly design, inextensible interfaces laying around, thats
> >why.
> This is a bad example, but a (perhaps?) good point. It seems it
> > There is a large perception of CORBA being slow, but for the most part it
> > is unjustified. I believe that the act of _designing_ a completely new
> CORBA is slow compared to some of the other solutions. The question I was
> trying to ask is whether you should put something smaller and
> > Of course. Which is why CORBA is about putting STRUCTURE in that stream
> > of random bytes coming over the wire. Why should I have to rewrite my
> > marshalling and demarshalling code every time I want to write a
> > server. read and write are fine. But sometimes I want a
> > structure.
> > > There is a large perception of CORBA being slow, but for the most part it
> > > is unjustified.
>
> Really? I have that same perception but I can't claim that I've measured it.
> On the other hand, I have measured the overhead of straight UDP, TCP, and
> Sun RPC ping/pong tests and you
> > > Oh, great. So we don't have to care about formatting changes. We just
> > > have to care about the data changes. IOW, we are shielded from the
> > > results of changes that should never happen in the first place. And the
> > > benefit being...?
> >
> > What the hell are you talking about?
> > 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
> > cat /mnt/www/www.kernel.org/index.html
>
> can you do ls /mnt/www/www.kernel.org/ as well? I'm interested, I came
> to conclusion that web filesystem is not possible... (If you can't do
Yes, if the server supports webDAV or something similar.
> listings, it is not really filesystem; you
On Thu, 5 Jul 2007, Al Viro wrote:
On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote:
Note that gcc rules for __attribute__() (and that's the only source
of rules we _have_ for the damn thing) clearly say that
int __user *p;
is the same thing as
int *__user p;
45 matches
Mail list logo
