Why no XML in the Kernel?

Why no XML in the Kernel?

[Ahmad Reza Cheraghi]

Can somebody tell me why the Kernel-Development dont
wanne have XML is being used in the Kernel??

Regards 

Ahmad Reza Cheraghi


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Why no XML in the Kernel?

[Nick Piggin]

Ahmad Reza Cheraghi wrote:
> Can somebody tell me why the Kernel-Development dont
> wanne have XML is being used in the Kernel??
> 

Because nobody has come up with a good reason why it
should be. Same as anything that isn't in the kernel.

Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: Why no XML in the Kernel?

[Nick Piggin]

James Courtier-Dutton wrote:

> I have a requirement to pass information from the kernel to user space. 
> The information is passed fairly rarely, but over time extra parameters 
> are added. At the moment we just use a struct, but that means that the 
> kernel and the userspace app have to both keep in step. If something 
> like XML was used, we could implement new parameters in the kernel, and 
> the user space could just ignore them, until the user space is upgraded.
> XML would initially seem a good idea for this, but are there any methods 
> currently used in the kernel that could handle these parameter changes 
> over time.
> 
> For example, should the sysfs be used for this?
> 
> Any comments?
> 

Yes use sysfs (or procfs if the information is related to a process).
Using ASCII text representation, and a single value per file is
noramlly the preferred method to do this I think.

Nick

-- 
SUSE Labs, Novell Inc.


Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: Why no XML in the Kernel?

[James Courtier-Dutton]

Nick Piggin wrote:

> Ahmad Reza Cheraghi wrote:
>
>> Can somebody tell me why the Kernel-Development dont
>> wanne have XML is being used in the Kernel??
>>
>
> Because nobody has come up with a good reason why it
> should be. Same as anything that isn't in the kernel.
>
> Nick
>
I have a requirement to pass information from the kernel to user space. 
The information is passed fairly rarely, but over time extra parameters 
are added. At the moment we just use a struct, but that means that the 
kernel and the userspace app have to both keep in step. If something 
like XML was used, we could implement new parameters in the kernel, and 
the user space could just ignore them, until the user space is upgraded.
XML would initially seem a good idea for this, but are there any methods 
currently used in the kernel that could handle these parameter changes 
over time.

For example, should the sysfs be used for this?

Any comments?

James

Re: Why no XML in the Kernel?

[James Bruce]

James Courtier-Dutton wrote:
> Nick Piggin wrote:
>> Ahmad Reza Cheraghi wrote:
>>> Can somebody tell me why the Kernel-Development dont
>>> wanne have XML is being used in the Kernel??
>>
>> Because nobody has come up with a good reason why it
>> should be. Same as anything that isn't in the kernel.
>> Nick
>>
> I have a requirement to pass information from the kernel to user space. 
> The information is passed fairly rarely, but over time extra parameters 
> are added. At the moment we just use a struct, but that means that the 
> kernel and the userspace app have to both keep in step. If something 
> like XML was used, we could implement new parameters in the kernel, and 
> the user space could just ignore them, until the user space is upgraded.
> XML would initially seem a good idea for this, but are there any methods 
> currently used in the kernel that could handle these parameter changes 
> over time.

If you only add parameters, why not use a struct with a length field? 
That can encode version information implicitly; You can assume 
everything beyond the length is not present in that ABI version.  If the 
interface is based on read(2), then you don't even need the length field 
in the structure, since everything can be handled by userspace 
specifying the length it wants as the read size parameter, and the 
kernel returning only the bytes for the fields it knows about.
  - Jim Bruce

> For example, should the sysfs be used for this?
> Any comments?
> James

Re: Why no XML in the Kernel?

[Bas Westerbaan]

Hello Nick,

 In case /proc or /sys wouldn't be preffered, a simple key value
binary format would do.

 First a key/value pair count. Followed by the key/value pairs, which
consist out of the value and key prefixed by their size.

 Your user and kernel code could ignore keys they don't regognize.

 A better way though, is negotiate what types of structures to pass.

 The user space program would support all previous version of the kernel module.

  Bas

On 10/2/05, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> James Courtier-Dutton wrote:
>
> > I have a requirement to pass information from the kernel to user space.
> > The information is passed fairly rarely, but over time extra parameters
> > are added. At the moment we just use a struct, but that means that the
> > kernel and the userspace app have to both keep in step. If something
> > like XML was used, we could implement new parameters in the kernel, and
> > the user space could just ignore them, until the user space is upgraded.
> > XML would initially seem a good idea for this, but are there any methods
> > currently used in the kernel that could handle these parameter changes
> > over time.
> >
> > For example, should the sysfs be used for this?
> >
> > Any comments?
> >
>
> Yes use sysfs (or procfs if the information is related to a process).
> Using ASCII text representation, and a single value per file is
> noramlly the preferred method to do this I think.
>
> Nick
>
> --
> SUSE Labs, Novell Inc.
>
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



--
Bas Westerbaan
http://blog.w-nz.com/
GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc

Re: Why no XML in the Kernel?

[Willy Tarreau]

On Sun, Oct 02, 2005 at 12:02:49PM +0100, James Courtier-Dutton wrote:
> Nick Piggin wrote:
> 
> >Ahmad Reza Cheraghi wrote:
> >
> >>Can somebody tell me why the Kernel-Development dont
> >>wanne have XML is being used in the Kernel??
> >>
> >
> >Because nobody has come up with a good reason why it
> >should be. Same as anything that isn't in the kernel.
> >
> >Nick
> >
> I have a requirement to pass information from the kernel to user space. 
> The information is passed fairly rarely, but over time extra parameters 
> are added. At the moment we just use a struct, but that means that the 
> kernel and the userspace app have to both keep in step. If something 
> like XML was used, we could implement new parameters in the kernel, and 
> the user space could just ignore them, until the user space is upgraded.
> XML would initially seem a good idea for this, but are there any methods 
> currently used in the kernel that could handle these parameter changes 
> over time.

Yes, look at /proc/meminfo for instance. Everytime you need to return
multiple values from a single file, you can easily do it with one key
per line using the following syntax :

   key: value [value ...]

It's also how SMTP and HTTP works and servers often send data that most
clients simply ignore.

Regards,
Willy

Re: Why no XML in the Kernel?

[Jon Masters]

On 10/2/05, Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com> wrote:

> Can somebody tell me why the Kernel-Development dont
> wanne have XML is being used in the Kernel??

I think it's mostly because the marketeers haven't got to everyone yet
:-) The kernel might be e-enabled, but it's not fully
iBuzzwordcompliant.

Besides, having a *fully* XML parser/generator in the kernel is
extremely braindead, even if it's called libkernelxml ("I'm not really
quite in the kernel really") or something. What's so wrong with really
simple files being exposed to userspace? Most of these are less than a
single page of data and it's just dandy like that.

Jon.

Re: Why no XML in the Kernel?

[Martin J. Bligh]

--Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com> wrote (on Sunday, October 02, 2005 02:41:42 -0700):

> Can somebody tell me why the Kernel-Development dont
> wanne have XML is being used in the Kernel??

Because nobody has yet discovered strong enough weed?

M.

Re: Why no XML in the Kernel?

[Nick Piggin]

Martin J. Bligh wrote:
> 
> --Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com> wrote (on Sunday, October 02, 2005 02:41:42 -0700):
> 
> 
>>Can somebody tell me why the Kernel-Development dont
>>wanne have XML is being used in the Kernel??
> 
> 
> Because nobody has yet discovered strong enough weed?
> 

Well I think _somebody_ has. They've just made the mistake
of not sending any to Linus before sending patches.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: Why no XML in the Kernel?

[Nix]

On 2 Oct 2005, Jon Masters suggested tentatively:
> Besides, having a *fully* XML parser/generator in the kernel is
> extremely braindead, even if it's called libkernelxml ("I'm not really
> quite in the kernel really") or something. What's so wrong with really
> simple files being exposed to userspace? Most of these are less than a
> single page of data and it's just dandy like that.

I beat off a suggestion last week[1] that the kernel should `not bother
with any of this /proc and /sys stuff' but just export a single vast
heap of XML, because XML is `properly structured'.

(As opposed to, oh, a filesystem, which is apparently not structured
enough.)

Considerations of ugliness and difficulty of implementing the equivalent
of writes to procs files did not shift the twit: but starting top on a
busy system and showing said twit the CPU load spikes as /proc/[0-9]*
got iterated over, and asking `how severe would this be if *all* of
/proc and /sys had to be generated for every single request?' seems to
have imparted enough clue.


I have a large notice by my desk at work reading simply `XML is not a
panacea'. It's amazing how few people wandering by read it.


[1] by someone who couldn't have implemented it in a month of Sundays,
    thankfully

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: Why no XML in the Kernel?

[Al Viro]

On Mon, Oct 03, 2005 at 04:08:43PM +0100, Nix wrote:
> Considerations of ugliness and difficulty of implementing the equivalent
> of writes to procs files did not shift the twit: but starting top on a
> busy system and showing said twit the CPU load spikes as /proc/[0-9]*
> got iterated over, and asking `how severe would this be if *all* of
> /proc and /sys had to be generated for every single request?' seems to
> have imparted enough clue.

Another fun consideration in that area is that XML (or s-exp, or trees,
whatever representation you prefer) has nothing to help with dynamic data
structures.  Exporting snapshots does not work since the real state
includes the information about locks being held - without that you
can't tell which invariants hold at the moment, since the real ones
include lock state.  And forcing all locks involved into known state
is nowhere near feasible, of course.  OTOH, exporting dynamic state
including locks and walking the damn thing is
	a) not feasible with XML
	b) would require giving userland way too much access to locking,
creating a nightmare wrt deadlock potential.

Re: Why no XML in the Kernel?

[Bill Davidsen]

James Courtier-Dutton wrote:
> Nick Piggin wrote:
> 
>> Ahmad Reza Cheraghi wrote:
>>
>>> Can somebody tell me why the Kernel-Development dont
>>> wanne have XML is being used in the Kernel??
>>>
>>
>> Because nobody has come up with a good reason why it
>> should be. Same as anything that isn't in the kernel.
>>
>> Nick
>>
> I have a requirement to pass information from the kernel to user space. 
> The information is passed fairly rarely, but over time extra parameters 
> are added. At the moment we just use a struct, but that means that the 
> kernel and the userspace app have to both keep in step. If something 
> like XML was used, we could implement new parameters in the kernel, and 
> the user space could just ignore them, until the user space is upgraded.
> XML would initially seem a good idea for this, but are there any methods 
> currently used in the kernel that could handle these parameter changes 
> over time.
> 
> For example, should the sysfs be used for this?
> 
> Any comments?

For decades people have been solving this with key:value, ignoring 
unknown keys. And using nice text format eliminates any endian and word 
size issues.

XML sounds like overkill for problems of this type.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Why no XML in the Kernel?

[Nix]

On Mon, 3 Oct 2005, Al Viro moaned:
> Another fun consideration in that area is that XML (or s-exp, or trees,
> whatever representation you prefer) has nothing to help with dynamic data
> structures.  Exporting snapshots does not work since the real state
> includes the information about locks being held - without that you
> can't tell which invariants hold at the moment, since the real ones
> include lock state.

Oh yes; the only practical way to get the system into a consistent state
would be to take out the BKL (the old, non-preemptible variant),
generate all that XML (for all of /proc and all of /sys!) and then
release it again.

Efficient this is *not*.

(at least, not the loony everything-in-one-big-file variant. Keeping the
current smaller files but making them XML is possible, but pointless:
the filesystem already provides the hierarchical structure in /sys, and
nothing can make /proc regular, so what's the point of adding an extra
layer of hierarchy that serves only to complicate parsing and make it
hard for *humans* to use?)

>                      And forcing all locks involved into known state
> is nowhere near feasible, of course.  OTOH, exporting dynamic state
> including locks and walking the damn thing is
> 	a) not feasible with XML

It's feasible, if you don't mind ps(1) becoming a DoS attack, and one
running instance of top(1) damn-nearly freezing the system.

It's just not *sane*.

> 	b) would require giving userland way too much access to locking,
> creating a nightmare wrt deadlock potential.

Indeed.

(Current rant: DRM churn, forcing one of abandonment of decent 3D
support, or upgrading of the X server to the bleeding-edge, or using an
old kernel with known security holes, or becoming enough of a DRI
developer to backport the changes, or using nothing but distro kernels
<=2.6.11. Most of these are not terribly feasible for me right now. Ah
well, my 3D card is total crap anyway. It's just a shame the X server
crashes whenever asked to do in-software 3D rendering...  time to
debug. I thought I might actually get some work done this evening. Fat
chance.)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: Why no XML in the Kernel?

[linux-os (Dick Johnson)]

On Mon, 3 Oct 2005, Nix wrote:

> On Mon, 3 Oct 2005, Al Viro moaned:
>> Another fun consideration in that area is that XML (or s-exp, or trees,
>> whatever representation you prefer) has nothing to help with dynamic data
>> structures.  Exporting snapshots does not work since the real state
>> includes the information about locks being held - without that you
>> can't tell which invariants hold at the moment, since the real ones
>> include lock state.
>
> Oh yes; the only practical way to get the system into a consistent state
> would be to take out the BKL (the old, non-preemptible variant),
> generate all that XML (for all of /proc and all of /sys!) and then
> release it again.
>
> Efficient this is *not*.
>
> (at least, not the loony everything-in-one-big-file variant. Keeping the
> current smaller files but making them XML is possible, but pointless:
> the filesystem already provides the hierarchical structure in /sys, and
> nothing can make /proc regular, so what's the point of adding an extra
> layer of hierarchy that serves only to complicate parsing and make it
> hard for *humans* to use?)
>
>>                      And forcing all locks involved into known state
>> is nowhere near feasible, of course.  OTOH, exporting dynamic state
>> including locks and walking the damn thing is
>> 	a) not feasible with XML
>
> It's feasible, if you don't mind ps(1) becoming a DoS attack, and one
> running instance of top(1) damn-nearly freezing the system.
>
> It's just not *sane*.
>
>> 	b) would require giving userland way too much access to locking,
>> creating a nightmare wrt deadlock potential.
>
> Indeed.
>
> (Current rant: DRM churn, forcing one of abandonment of decent 3D
> support, or upgrading of the X server to the bleeding-edge, or using an
> old kernel with known security holes, or becoming enough of a DRI
> developer to backport the changes, or using nothing but distro kernels
> <=2.6.11. Most of these are not terribly feasible for me right now. Ah
> well, my 3D card is total crap anyway. It's just a shame the X server
> crashes whenever asked to do in-software 3D rendering...  time to
> debug. I thought I might actually get some work done this evening. Fat
> chance.)
>

...could get rid of all the kernel function codes and just put a
XML interpreter inside the kernel. That way, web-page designers
could become kernel developers overnight.

> --
> `Next: FEMA neglects to take into account the possibility of
> fire in Old Balsawood Town (currently in its fifth year of drought
> and home of the General Grant Home for Compulsive Arsonists).'
>            --- James Nicoll
> -

XML inside the kernel is like BASIC inside the kernel. It
just doesn't belong there, even though it would work.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Why no XML in the Kernel?

[Dave Airlie]

>
> (Current rant: DRM churn, forcing one of abandonment of decent 3D
> support, or upgrading of the X server to the bleeding-edge, or using an
> old kernel with known security holes, or becoming enough of a DRI
> developer to backport the changes, or using nothing but distro kernels
> <=2.6.11. Most of these are not terribly feasible for me right now. Ah
> well, my 3D card is total crap anyway. It's just a shame the X server
> crashes whenever asked to do in-software 3D rendering...  time to
> debug. I thought I might actually get some work done this evening. Fat
> chance.)

This is just mach64, we don't have mach64 support in the kernel so it
has nothing to do with the kernel... I've no idea why mach64 broke but
upgrading everything won't fix it.. the kernel-drm and userspace do
not need to be kept in any sort of lockstep, and the mach64 dri code
hasn't been touched by anyone in > 1 year probably even two.. (I was
last person to own one to test it on...)

If you could nail down exactly when it went south then we can fix
it... but giving out here won't help anyone..

Dave.

Re: Why no XML in the Kernel?

[Nix]

On Thu, 6 Oct 2005, Dave Airlie announced authoritatively:
>> (Current rant: DRM churn, forcing one of abandonment of decent 3D
>> support, or upgrading of the X server to the bleeding-edge, or using an
>> old kernel with known security holes, or becoming enough of a DRI
>> developer to backport the changes, or using nothing but distro kernels
>> <=2.6.11. Most of these are not terribly feasible for me right now. Ah
>> well, my 3D card is total crap anyway. It's just a shame the X server
>> crashes whenever asked to do in-software 3D rendering...  time to
>> debug. I thought I might actually get some work done this evening. Fat
>> chance.)
> 
> This is just mach64, we don't have mach64 support in the kernel so it
> has nothing to do with the kernel... I've no idea why mach64 broke but

I misspoke. Some of the non-DRM API changes around 2.6.12 broke the
6.8.2 mach64 module in DRI CVS; the development version builds again,
and nearly works.

> upgrading everything won't fix it.. the kernel-drm and userspace do
> not need to be kept in any sort of lockstep,

I could swear that I've encountered problems in the past due to
upgrading one and not the other, but since I can't actually remember
what those problems *were*, I'll shut up.

>                                              and the mach64 dri code
> hasn't been touched by anyone in > 1 year probably even two.. (I was
> last person to own one to test it on...)

I'd not have got a mach64 if I hadn't got the machine free. I hear
R9200s are the most useful 3D cards with free drivers around at the
moment: I suppose I should get one. (It's not as though the Mach64's
hardware 3D support is significantly faster than software rendering on
this 1300MHz Athlon anyway.)

> If you could nail down exactly when it went south then we can fix
> it... but giving out here won't help anyone..

It was just a random rant: I know that I can't really complain until
I've tried the development version, so I've built up 6.8.99.900, which
nearly half sort-of works, modulo only fdo bugs #4574 (which bug breaks
the mach64 DRM module, but at least it builds and modprobes OK), and
#4696 (which kills the X server and is probably a Mesa bug rather than
anything Mach64-specific).

No kernel-tree problems, really, and I'm not complaining about the speed
of kernel development at all, let alone asking for some mythical and
restrictive stable module API. I'm just wondering if I'll ever be able
to use DRI for more than a month at a time without something breaking it
:( such are the risks of using a card with out-of-tree DRM support.


(Aside: I must say I'm damn impressed by the X server's internal API
stability. I screwed up the installation of X.org 6.8.99.900, and for a
day or so was unknowingly running the X.org 6.8.2 X server against the
6.8.99.900 modules. Except for problems drawing certain small pixmaps,
it seemed to work perfectly well!)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: Why no XML in the Kernel?

[jmerkey]

Dave Airlie wrote:

>>Ah. So, er, the DRM<-> userspace protocol is stable, then?
>>
>>Looks like I was working on bad assumptions (assuming the DRM and X were
>>tied). I'm not sure where those assumptions came from. Possibly just
>>that they shared a CVS repo, although I'd hope I'd had more evidence
>>than that. I realy can't recall.
>>    
>>
>
>In theory yes, on occasion I do get bugs that break XFree86 4.3, but
>these are bugs as opposed to design decisions, upgrading the kernel
>should never require upgrading to a new  version of X or anything like
>that, however upgrading X can sometimes require a newer kernel in
>order to take advantage of newer drm features.. but X should always
>work with the older drms...
>
>Dave.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
How about putting the ability to disable graphics mode in the kernel and 
moving this capability from X, and saving the video state. Would make 
kernel debuggers work a hell of a lot better when the damn thing crashes 
in X in the kernel. At least then the screen won;t be locked up (of 
course you can type "reboot " from memory while the system is still hung 
in X).

Jeff

Re: Why no XML in the Kernel?

[Dave Airlie]

> >
> > This is just mach64, we don't have mach64 support in the kernel so it
> > has nothing to do with the kernel... I've no idea why mach64 broke but
>
> I misspoke. Some of the non-DRM API changes around 2.6.12 broke the
> 6.8.2 mach64 module in DRI CVS; the development version builds again,
> and nearly works.
>

But that's my point if you had a previously working mach64 with 6.8.2
with a DRM from around then, and a kernel upgrade broke the DRM you
should be just able to upgrade the DRM to the latest DRM CVS, there
isn't any such thing as a 6.8.2 DRM, you'll only cause much more
issues trying to fix an issue in the kernel side by also
simultaneously upgrading userspace... as you've no fixed working point
to try from..

The mach64 drm is in CVS on cvs.freedesktop.org:/cvs/dri and the module is drm..

Dave.

Re: Why no XML in the Kernel?

[Nix]

On Thu, 6 Oct 2005, Dave Airlie uttered the following:
>> I misspoke. Some of the non-DRM API changes around 2.6.12 broke the
>> 6.8.2 mach64 module in DRI CVS; the development version builds again,
>> and nearly works.
> 
> But that's my point if you had a previously working mach64 with 6.8.2
> with a DRM from around then, and a kernel upgrade broke the DRM you
> should be just able to upgrade the DRM to the latest DRM CVS, there
> isn't any such thing as a 6.8.2 DRM,

Ah. So, er, the DRM<-> userspace protocol is stable, then?

Looks like I was working on bad assumptions (assuming the DRM and X were
tied). I'm not sure where those assumptions came from. Possibly just
that they shared a CVS repo, although I'd hope I'd had more evidence
than that. I realy can't recall.

>                                      you'll only cause much more
> issues trying to fix an issue in the kernel side by also
> simultaneously upgrading userspace... as you've no fixed working point
> to try from..

That's OK, the -RC0 X server actually works better than the 6.8.2 one
for my application, and this gives me an excuse to report some bugs
before 6.9/7.0 is released :)


Thanks for the advice, anyway: I'll certainly bear it in mind in future.

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: Why no XML in the Kernel?

[Dave Airlie]

>
> Ah. So, er, the DRM<-> userspace protocol is stable, then?
>
> Looks like I was working on bad assumptions (assuming the DRM and X were
> tied). I'm not sure where those assumptions came from. Possibly just
> that they shared a CVS repo, although I'd hope I'd had more evidence
> than that. I realy can't recall.

In theory yes, on occasion I do get bugs that break XFree86 4.3, but
these are bugs as opposed to design decisions, upgrading the kernel
should never require upgrading to a new  version of X or anything like
that, however upgrading X can sometimes require a newer kernel in
order to take advantage of newer drm features.. but X should always
work with the older drms...

Dave.

Re: Why no XML in the Kernel?

[Dave Airlie]

> >
> How about putting the ability to disable graphics mode in the kernel and
> moving this capability from X, and saving the video state. Would make
> kernel debuggers work a hell of a lot better when the damn thing crashes
> in X in the kernel. At least then the screen won;t be locked up (of
> course you can type "reboot " from memory while the system is still hung
> in X).
>

It's been on the todo list for a long while... there's been talks at
different events about it, there'll be a talk at LCA from me again
about it and what has happened since KS (not a huge amount)....

We've nearly all agreed on a direction, we haven't found anyone with
the bandwidth to actually move things in that direction... (or at
least no-one has said to me heres some money  go do this thing... :-)

Dave.

Re: Why no XML in the Kernel?

[Matan Ziv-Av]

On Thu, 6 Oct 2005, Dave Airlie wrote:

>> How about putting the ability to disable graphics mode in the kernel and
>> moving this capability from X, and saving the video state. Would make
>> kernel debuggers work a hell of a lot better when the damn thing crashes
>> in X in the kernel. At least then the screen won;t be locked up (of
>> course you can type "reboot " from memory while the system is still hung
>> in X).

You don't need to reboot. You can use some tools to restore text 
mode - svgalib comes with three such tools, that work in large majority
of the cases:
textmode (on all platforms), mode3 and vga_reset (i386 only).

> It's been on the todo list for a long while... there's been talks at
> different events about it, there'll be a talk at LCA from me again
> about it and what has happened since KS (not a huge amount)....
>
> We've nearly all agreed on a direction, we haven't found anyone with
> the bandwidth to actually move things in that direction... (or at
> least no-one has said to me heres some money  go do this thing... :-)

I intend to put that part of svgalib in kernel (restoring modes), 
since it would make the most complicated part of svgalib -- console 
switch handling -- much simpler. The problem is that svgalib only 
handles video mode, totally ignoring 2D/3D engines, so it might


-- 
Matan Ziv-Av.                         matan@svgalib.org

Re: Why no XML in the Kernel?

[Luke Kenneth Casson Leighton]

> I have a requirement to pass information from the kernel to user space.
> The information is passed fairly rarely, but over time extra parameters
> are added. At the moment we just use a struct, but that means that the
> kernel and the userspace app have to both keep in step. If something
> like XML was used, we could implement new parameters in the kernel, and
> the user space could just ignore them, until the user space is upgraded.
> XML would initially seem a good idea for this, but are there any methods
> currently used in the kernel that could handle these parameter changes
> over time.

 okay.

 storing data in binary format is efficient space-wise, clearly
 optimal, but is difficult to interpret unless you play a lot
 of chess and music.

 XML is inefficient memory and processing wise for storage of
 data, but it is structured, is easy for normal humans to read and
 understand as long as microsoft doesn't get their hands on it.

 the guy who wrote XMLRPC more than 5 or so years ago did so as
 an experiment in order to get himself onto the SOAP committee.

 now we have .NET, based on SOAP, and everyone hates it.  them.
 .NET _and_ SOAP.  even if SOAP _can_ be implemented in 6,000 lines
 of python.


 ramming structs in home-grown marshalled format across
 processes is fine (i do it all the time) ...

 ... until you get large complex data structures, see this url
 for an example of horrendously complex multi-linked-listed,
 multi-unioned interlinked and _recursive_ data structures
 with forward references, that would be a complete nightmare
 without automated tools:

 http://cvs.sourceforge.net/viewcvs.py/oser/exchange5.5/exploration/test/emsabp/emsabp.idl?rev=1.1&view=markup

 if it wasn't for freedce, the creation of, management and
 use of such data structures would be a complete nightmare.

 no i do _not_ recommend that freedce be used inside the linux kernel.

 however what i _would_ advocate for special and specific
 circumstances would be to seek out the "pickling" side of
 freedce, run the IDL compiler and end up with some c-code
 that can then be used as a form of structured storage:

	 http://www.opengroup.org/tech/rfc/mirror-rfc/rfc2.1.txt
	
 it's a bit of a pain that the code generated stuffs 20 bytes
 of garbage (the uuid and version number that you specified
 in the .idl file) but that can always be stripped off after
 encoding and re-added manually at decode time (or the code in
 freedce just chiselled away) - all you lose by following that
 trick is the unpickling code's ability to tell you "yes, you
 handed me the wrong blob there, bob".  as a result, faking
 up the version number and uuid on the wrong blob will trash
 your function call stack - just in the same way as if you
 got a printf with the wrong number of arguments.

 what OSF call "pickling" is also known as persistent or structured
 storage.

 it's a friggin sight better than contemplating XML, but it also comes
 with a price tag: in this case, nearly 70,000 lines of library code
 that "encapsulates" and "extracts" the data structures for you, at
 runtime [yes, you can supply your own malloc and free routines]

 in the cases where data structures are _that_ complex, or where time is
 of the essence, or you have a significant amount of regular restructuring
 anticipated before settling on your final data structures and APIs, the
 use of an automated "pickler" - one that does binary NOT some stupid
 XMsmelly format - is a good idea.

 where it's NOT a good idea is where you have _really_ simple data
 structures, or your data structures simply ain't gonna change much
 ever, or you have exceptionally careful programmers who have lots of
 time on their hands to go over each line of the hand-marshalling and
 unmarshalling code, line-by-line.

 and yes, as i understand it, the GNU/Hurd has so much structured
 storage passing going on that yes, they wrote an IDL compiler and a
 mini RPC system (oh, and they have microkernel to make use of it,
 too.  nyer :)

 one of these fine decades i will experiment with using
 freedce instead of their home-grown IDL compiler and see if
 it's possible to utilise freedce networking to move entire
 processes, uninterrupted, from one machine to another.

 basically, these tools allow the specialist job of turning complex data
 structures into data streams and back again to be separated from the
 specialist job of writing a decent kernel.

 if your data structures aren't that complex, you really _don't_ need
 specialist tools - XML or binary.

 l.

 p.s. hurrah!  first post on LVML :)

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

Re: Why no XML in the Kernel?

[Horst von Brand]

Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

[...]

>  it's a friggin sight better than contemplating XML, but it also comes
>  with a price tag: in this case, nearly 70,000 lines of library code
>  that "encapsulates" and "extracts" the data structures for you, at
>  runtime [yes, you can supply your own malloc and free routines]

70 KSLOC is a /lot/, the benefit of having that in kernel would have to be
very large to justify it. And in the frame of an operating system that
believes in flat ("just stream of bytes") interfaces throughout and
hopefully very simple tools on top ("cat", "more", "grep") that are
combined by the user to do complex stuff I just don't see it.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513