> > 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
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
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 FTP
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
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
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
> 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
> > > 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
> > 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
* 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
[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
> 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
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 design
[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 tests
* 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 that
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
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
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
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
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 space
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:
> > 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
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
> > 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
/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
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
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
/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
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 for
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
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
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 the hell
40 matches
Mail list logo
