> > 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
Hi!
> The cool thing is that the CorbaFS userspace server can implement any
> kind of filesystem you want, as long as it follows the CorbaFS
> interface! The current implementation exports the filesystem on the
> host machine that it is running on, similar to NFS. But we also have
> ideas for F
Alexander Viro <[EMAIL PROTECTED]> writes:
> ioctl() is avoidable. Proof: Plan 9. They don't _have_ that system call.
> It doesn't mean that we should (or could) remove it. It _does_ mean that
> new APIs do not need it.
*I* sure wish we could. From the standpoint of trying to trace system calls,
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > Yes, I did. What I don't understand is how kernel mechanism for marshalling
> > would make your life easier wrt changes.
>
> I gave a very simple example of how an interface could be designed and
> then later extended without breaking any user spac
> But alan, that's the beautiful thing. Given a CORBA object, you can
> understand its structure without knowing exactly what the contents
> are. You can effectively derive it's prototype just by inspecting it.
Oh dear this isnt going in is it.
Look I know the prototype of every single lisp t
> > > 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.
Fredrik Vraalsen wrote:
> The cool thing is that the CorbaFS userspace server can implement any
> kind of filesystem you want, as long as it follows the CorbaFS
> interface!
Sorry, it's yet another one. Or does it do something different?
(YAO hasn't stopped me working on userspace filesystems ei
> > 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
* Rik van Riel
|
| On Wed, 13 Dec 2000, Chris Lattner wrote:
|
| > 1. kORBit adds about 150k of code to the 2.4t10 kernel.
| > 2. kNFS adds about 100k of code to the 2.4t10 kernel.
| > 3. kORBit can do everything kNFS does, plus a WHOLE lot more: For example
| >implement an NFS like server th
[Alan DID not say this:]
> > 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 te
> 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
> protocol, standardizing it, and making it actually work would be a huge
> process that would basically reinvent CORBA (obviously some of the desig
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > 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
> > 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
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> > > 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 e
> > 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
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> /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 f
/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
On Wed, 13 Dec 2000, Chris Lattner wrote:
> CORBA, today, gives us superior interoperability (through IIOP), with
> extensibility for the future. As Alexander Viro mentions, 9P may be a
> better protocol for local communications...
Local? Funny. It lives atop of TCP or IL quite fine.
> > 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
21 matches
Mail list logo
