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
> Also, 9P is a general communications framework only in the context of
> Plan9 itself. In reality it only applys directly/well to filesystem
> related issues... the reason it works well in Plan9 is that _everything_
> is a file (part of the beauty of plan9).
So... in a 9P-enabled system, you
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
/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
> > 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
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.
Alexander Viro wrote:
> p9fs exists. I didn't see these patches since August, but probably I can poke
> Roman into porting it to the current tree. 9P is quite simple and unlike
> CORBA it had been designed for taking kernel stuff to userland. Besides,
> authors definitely understand UNIX...
I
> > 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
> > 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
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_)
On Thu, 14 Dec 2000, Alan Cox wrote:
> > 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
> 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
[EMAIL PROTECTED] said:
> 1. Boot kernel
> 2. Install corbafs module for example
You misspelled 'codafs' :)
> 3. Start test filesystem in user space
> 4. mount test user space filesystem
> 5. test it, oh crap, it segfaulted.
> 6. CorbaFS gets exceptions trying to communicate to server, which
[EMAIL PROTECTED] said:
1. Boot kernel
2. Install corbafs module for example
You misspelled 'codafs' :)
3. Start test filesystem in user space
4. mount test user space filesystem
5. test it, oh crap, it segfaulted.
6. CorbaFS gets exceptions trying to communicate to server, which it
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 problems
On Thu, 14 Dec 2000, Alan Cox wrote:
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
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
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.
Alexander Viro wrote:
p9fs exists. I didn't see these patches since August, but probably I can poke
Roman into porting it to the current tree. 9P is quite simple and unlike
CORBA it had been designed for taking kernel stuff to userland. Besides,
authors definitely understand UNIX...
I
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
Also, 9P is a general communications framework only in the context of
Plan9 itself. In reality it only applys directly/well to filesystem
related issues... the reason it works well in Plan9 is that _everything_
is a file (part of the beauty of plan9).
So... in a 9P-enabled system, you
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
On Wed, 13 Dec 2000, Chris Lattner wrote:
plan-9.bell-labs.com/sys/man/
Arrgh. s/plan-9/plan9/. My apologies.
Err... yeah, so you're effectively mapping UNIX/POSIX across 9P. That's
not very creative, and you could do the same thing with CORBA. I ask
again, "How much development
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
According to Alexander Viro:
9P is quite simple and unlike CORBA it had been designed for taking
kernel stuff to userland. Besides, authors definitely understand
UNIX...
As nice as 9P is, it'll need some tweaks to work with Linux.
For example, it limits filenames to 30 characters; that's not
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
According to Alexander Viro:
9P is quite simple and unlike CORBA it had been designed for taking
kernel stuff to userland. Besides, authors definitely understand
UNIX...
As nice as 9P is, it'll need some tweaks to work with Linux.
For
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
According to Alexander Viro:
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
According to Alexander Viro:
9P is quite simple and unlike CORBA it had been designed for taking
kernel stuff to userland. Besides, authors definitely understand
According to Alexander Viro:
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
According to Alexander Viro:
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
According to Alexander Viro:
9P is quite simple and unlike CORBA it had been designed for taking
kernel stuff to userland.
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
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
As long as names are to be created, or at least understood, by humans,
there will be some limit on *usable* length. In my experience, 255 is
above that limit, but 30 is below it. And I cut my teeth on a system
that had exactly that length
At 12:15 AM 12/14/2000 -0500, you wrote:
Hmm... Cutoff seems to sit somewhere around 45 - above that there are only
apt-get droppings and they definitely are over the top. Dunno, you may be
right, but looks like I never had a need to create anything that long.
It's always good to be able to
On Wed, 13 Dec 2000, Chris Lattner wrote:
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
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
On Thu, 14 Dec 2000, josef [iso-8859-1] höök wrote:
Chip Salzenberg wrote:
According to Alexander Viro:
9P is quite simple and unlike CORBA it had been designed for taking
kernel stuff to userland. Besides, authors definitely understand
UNIX...
As nice as 9P is, it'll need
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
josef höök wrote:
>
> What about implementing 9P instead
That would rock. Plan9 is unix done the right way -- i.e., the fully
consistent way. I'd love to see 9p in Linux. We're heading that
direction anyway, with procfs, devfs, etc.
-
To unsubscribe from this list: send the line "unsubscribe
josef höök wrote:
What about implementing 9P instead
That would rock. Plan9 is unix done the right way -- i.e., the fully
consistent way. I'd love to see 9p in Linux. We're heading that
direction anyway, with procfs, devfs, etc.
-
To unsubscribe from this list: send the line "unsubscribe
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
Ben Ford wrote:
> Why would you *ever* want to write a device driver in perl???
Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot
S20 runs in userspace. Seems a safer place to do things.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi!
> > This email is here to announce the availability of a port of ORBit (the
> > GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
> > our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
> > allows you to write kernel extensions in CORBA and have
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> > You do realize what "evolution" means? I'm not talking about the bugs
> > in implementation. I'm talking about botched design. _That_ never gets
> > fixed. Show me one example when that would happen and I might consider
> > taking such possibility
> You do realize what "evolution" means? I'm not talking about the bugs
> in implementation. I'm talking about botched design. _That_ never gets
> fixed. Show me one example when that would happen and I might consider
> taking such possibility seriously.
That's what I am talking about in my
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> I do not understand this
> "i saw it - yuck! - and now i want to kill it "
s/want to kill it/do not want to touch it/
> point of view.
> As I tried to point out. Things evolve. And
> the evolution has the right do things wrong.
> Next evolution
Alexander Viro wrote:
>
> On Mon, 11 Dec 2000, Martin Dalecki wrote:
>
> > Please don't put KDE into the same bunch as gnome or
> > windows. KDE is in fact *well designed*! In esp. 2.0
>
> 'Tis funny, you know, because ISTR that the bloody thing
> got the same problems with the program sizes,
- Original Message -
From: J . A . Magallon <[EMAIL PROTECTED]>
To: Martin Dalecki <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 8:47 AM
Subject: Re: ANNOUNCE: Linux Kernel ORB: kORBit
>
> On Mon, 11 Dec 2000 14:38:52 Martin Dalec
On Mon, 11 Dec 2000, Martin Dalecki wrote:
> Please don't put KDE into the same bunch as gnome or
> windows. KDE is in fact *well designed*! In esp. 2.0
'Tis funny, you know, because ISTR that the bloody thing
got the same problems with the program sizes, API bloat and lack of
orthogonality.
On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote:
>
> Please don't put KDE into the same bunch as gnome or
> windows. KDE is in fact *well designed*! In esp. 2.0
>
That is why you need a supercomputer to run KDE at acceptable interactive
speeds...
--
Juan Antonio Magallon Lacarta
Dietmar Kling wrote:
>
> Ok guys i take your arguments...
> (i really loved to hear them)
>
> and i'd like to continue them in a
> private discussion( but i am
> tired now ... :) )
>
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like
Dietmar Kling wrote:
Ok guys i take your arguments...
(i really loved to hear them)
and i'd like to continue them in a
private discussion( but i am
tired now ... :) )
but a last one i cannot resist...
sarcasm
but why are your ideas not widespread and
so successful like
On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote:
Please don't put KDE into the same bunch as gnome or
windows. KDE is in fact *well designed*! In esp. 2.0
That is why you need a supercomputer to run KDE at acceptable interactive
speeds...
--
Juan Antonio Magallon Lacarta
- Original Message -
From: J . A . Magallon [EMAIL PROTECTED]
To: Martin Dalecki [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, December 11, 2000 8:47 AM
Subject: Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote:
Please don't put KDE
Alexander Viro wrote:
On Mon, 11 Dec 2000, Martin Dalecki wrote:
Please don't put KDE into the same bunch as gnome or
windows. KDE is in fact *well designed*! In esp. 2.0
raised brows 'Tis funny, you know, because ISTR that the bloody thing
got the same problems with the program
On Mon, 11 Dec 2000, Dietmar Kling wrote:
I do not understand this
"i saw it - yuck! - and now i want to kill it "
s/want to kill it/do not want to touch it/
point of view.
As I tried to point out. Things evolve. And
the evolution has the right do things wrong.
Next evolution step
You do realize what "evolution" means? I'm not talking about the bugs
in implementation. I'm talking about botched design. _That_ never gets
fixed. Show me one example when that would happen and I might consider
taking such possibility seriously.
That's what I am talking about in my "mean"
Hi!
This email is here to announce the availability of a port of ORBit (the
GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
allows you to write kernel extensions in CORBA and have the
Ben Ford wrote:
Why would you *ever* want to write a device driver in perl???
Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot
S20 runs in userspace. Seems a safer place to do things.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
In article <[EMAIL PROTECTED]> you wrote:
> Why would you *ever* want to write a device driver in perl???
Actually there is kind of device driver in perl, and besides it's
performance I think it proofed that a High-Level Language can do good for
rapid prototyping.
http://www.inter-mezzo.org - a
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like kde,gnome,windows?
> maybe because they suck at some point?
>
>
> Regards (and please flame me private ... :))
Last time I checked you needed a kernel...
-d
begin:vcard
n:Ford;David
Ok guys i take your arguments...
(i really loved to hear them)
and i'd like to continue them in a
private discussion( but i am
tired now ... :) )
but a last one i cannot resist...
but why are your ideas not widespread and
so successful like kde,gnome,windows?
maybe because they suck at
On Sat, 9 Dec 2000, Alan Cox wrote:
> > > From what I've seen in GNOME it's mostly about avoiding pipes
> > > religiously and putting everything and a kitchen sink into the same
> > > process. I'm not saying that it has no valid uses, but it definitely
> > > had contributed to the bloat in
> > From what I've seen in GNOME it's mostly about avoiding pipes
> > religiously and putting everything and a kitchen sink into the same
> > process. I'm not saying that it has no valid uses, but it definitely
> > had contributed to the bloat in case of GNOME.
> >
>
> Please consider to read
>
> From what I've seen in GNOME it's mostly about avoiding pipes
> religiously and putting everything and a kitchen sink into the same
> process. I'm not saying that it has no valid uses, but it definitely
> had contributed to the bloat in case of GNOME.
>
Please consider to read this
I wrote:
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase people who designed the thing are culturally incompatible with
> UNIX.
Hrrm. After rereading... I suspect that I wasn't clear
On Sat, 9 Dec 2000, Alan Cox wrote:
> > Yeah... "Infinitely extendable API" and all such. Roughly translated
> > as "we can't live without API bloat". Frankly, judging by the GNOME
> > codebase people who designed the
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase people who designed the thing are culturally incompatible with
> UNIX.
Oh they are definitely unix people, but ORBit is about solving a very
Alexander Viro wrote:
> > It was just an example. Basically, you'd be able to do in with just
> > about any language that has ORBit bindings.
>
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase
Alexander Viro wrote:
It was just an example. Basically, you'd be able to do in with just
about any language that has ORBit bindings.
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people who designed the thing are culturally incompatible with
UNIX.
Oh they are definitely unix people, but ORBit is about solving a very
On Sat, 9 Dec 2000, Alan Cox wrote:
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people who designed the thing are
I wrote:
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people who designed the thing are culturally incompatible with
UNIX.
Hrrm. After rereading... I suspect that I wasn't clear
shrug From what I've seen in GNOME it's mostly about avoiding pipes
religiously and putting everything and a kitchen sink into the same
process. I'm not saying that it has no valid uses, but it definitely
had contributed to the bloat in case of GNOME.
Please consider to read this
shrug From what I've seen in GNOME it's mostly about avoiding pipes
religiously and putting everything and a kitchen sink into the same
process. I'm not saying that it has no valid uses, but it definitely
had contributed to the bloat in case of GNOME.
Please consider to read this
On Sat, 9 Dec 2000, Alan Cox wrote:
shrug From what I've seen in GNOME it's mostly about avoiding pipes
religiously and putting everything and a kitchen sink into the same
process. I'm not saying that it has no valid uses, but it definitely
had contributed to the bloat in case of
Ok guys i take your arguments...
(i really loved to hear them)
and i'd like to continue them in a
private discussion( but i am
tired now ... :) )
but a last one i cannot resist...
sarcasm
but why are your ideas not widespread and
so successful like kde,gnome,windows?
maybe because they suck
but a last one i cannot resist...
sarcasm
but why are your ideas not widespread and
so successful like kde,gnome,windows?
maybe because they suck at some point?
/sarcasm
Regards (and please flame me private ... :))
Last time I checked you needed a kernel...
-d
begin:vcard
In article [EMAIL PROTECTED] you wrote:
Why would you *ever* want to write a device driver in perl???
Actually there is kind of device driver in perl, and besides it's
performance I think it proofed that a High-Level Language can do good for
rapid prototyping.
http://www.inter-mezzo.org - a
> > * We can now write device drivers in perl, and let them run on the iMAC
> > across the hall from you. :)
>
> Why would you *ever* want to write a device driver in perl???
So you can easily facilitate opportunities for viruses ;)
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
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.
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the
Chris Lattner wrote:
> This email is here to announce the availability of a port of ORBit (the
> GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
> our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
> allows you to write kernel extensions in CORBA
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???
--
=
Mohammad A. Haque
In article <[EMAIL PROTECTED]> you wrote:
> This email is here to announce the availability of a port of ORBit (the
> GNOME ORB) to the Linux kernel.
OMG you guys are so cool :)
Hey, this is real craftsmanship (not sure if it useful :)
Does this revamp the Micro Kernel Discussin? ONLY KIDDING
In article [EMAIL PROTECTED] you wrote:
This email is here to announce the availability of a port of ORBit (the
GNOME ORB) to the Linux kernel.
OMG you guys are so cool :)
Hey, this is real craftsmanship (not sure if it useful :)
Does this revamp the Micro Kernel Discussin? ONLY KIDDING :)
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???
--
=
Mohammad A. Haque
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.
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the
* We can now write device drivers in perl, and let them run on the iMAC
across the hall from you. :)
Why would you *ever* want to write a device driver in perl???
So you can easily facilitate opportunities for viruses ;)
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
Chris Lattner wrote:
This email is here to announce the availability of a port of ORBit (the
GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
allows you to write kernel extensions in CORBA and
101 - 191 of 191 matches
Mail list logo
