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;
Quic
> > 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 c
> > 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
> > > 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?
> > > 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
> > 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. 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 f
> >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.
> 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 deta
> > 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 kOR
> > 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 old
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
> 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
> marshalling-r
> > 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.
> > > 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 loo
> > 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
> > 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 userl
/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 no
> > 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
> > 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 conc
> > 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
> > > 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 about
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
nly user level code 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
seme
24 matches
Mail list logo
