On 1/11/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
Depends. The kernel _can_ shut down OF; in that case, it
becomes responsible for passing the device tree along to
the kexec'd kernel.
so we will need the non-callback support anyway, it seems?
thanks
ron
-
To unsubscribe from this
On 1/11/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS, and returning
sanely to the firmware.
And why is it we need to do that, presently? And how, in a virtualized
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch
* ron minnich <[EMAIL PROTECTED]> [070111 18:39]:
> I'd like to put in my $.02 in favor of having a way to pass the OF
> device tree to the kernel, in much the same way we pass stuff like
> ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
On 1/11/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
Wonderful! If the non-callback version works out, then we can greatly
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mitch Bradley wrote:
Request for comments.
Sorry to revive this thread, I just ran through the discussion. I'm
about 50% in agreement with the idea.
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and
Mitch Bradley wrote:
Request for comments.
Sorry to revive this thread, I just ran through the discussion. I'm
about 50% in agreement with the idea.
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On 1/11/07, Mitch Bradley [EMAIL PROTECTED] wrote:
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
Wonderful! If the non-callback version works out, then we can greatly
widen
* ron minnich [EMAIL PROTECTED] [070111 18:39]:
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the
On 1/11/07, Stefan Reinauer [EMAIL PROTECTED] wrote:
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS, and returning
sanely to the firmware.
And why is it we need to do that, presently? And how, in a virtualized
On 1/11/07, Segher Boessenkool [EMAIL PROTECTED] wrote:
Depends. The kernel _can_ shut down OF; in that case, it
becomes responsible for passing the device tree along to
the kexec'd kernel.
so we will need the non-callback support anyway, it seems?
thanks
ron
-
To unsubscribe from this
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 16:23:53 +0100
> >>> therefore you can't let multiple CPUs call
> >>> into OFW at one time. You must use some kind of locking mechanism,
> >>> and that locking mechanism is not simple because it has to not just
> >>> stop the
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply
> In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
> on machines with USB keyboards, because sharing the USB host
> controller is beyond non-trivial. I've never implemented support
> for that on sparc64 and I frankly have no desire to do the work
> necessary to support that.
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:13:39 +0100 (MET)
>
> On Jan 3 2007 01:52, Segher Boessenkool wrote:
> >> > Leaving aside the issue of in-memory or not, I don't think
> >> > it is realistic to think any completely common implementation
> >> > will work for this
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:14:34 +0100
> [snipping a bit for now]
>
> > and then, "fix"
> > that so that it works on x86 :-)
>
> That works, if the goal is to just add x86/OLPC to the list of
> platforms that have a device tree fs. I thought the plan
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:52:06 +0100
> >> Leaving aside the issue of in-memory or not, I don't think
> >> it is realistic to think any completely common implementation
> >> will work for this -- it might for current SPARC+PowerPC+OLPC,
> >> but more
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:48:02 +0100
> > therefore you can't let multiple CPUs call
> > into OFW at one time. You must use some kind of locking mechanism,
> > and that locking mechanism is not simple because it has to not just
> > stop the other cpus,
On Jan 3 2007 01:52, Segher Boessenkool wrote:
>> > Leaving aside the issue of in-memory or not, I don't think
>> > it is realistic to think any completely common implementation
>> > will work for this -- it might for current SPARC+PowerPC+OLPC,
>> > but more stuff will be added over time...
>>
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, "fix"
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
> The biggest problem is the huge collection of workarounds we have
> for PowerPC alone already -- if that can be moved into some
> quirk collection thing, where certain quirks are only run on some
> systems, it might scale.
Well, if you notice, I've been moving most of such workarounds to
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:40:17 +0100
> >> The kernel doesn't care if one CPU is in OF land while the others
> >> are doing other stuff -- well you have to make sure the OF won't
> >> try to use a hardware device at the same time as the kernel, true.
>
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:37:32 +0100
> Leaving aside the issue of in-memory or not, I don't think
> it is realistic to think any completely common implementation
> will work for this -- it might for current SPARC+PowerPC+OLPC,
> but more stuff will be
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:28:21 +0100
> >> Not single thread -- but a "global OF lock" yes. Not that
> >> it matters too much, (almost) all property accesses are init
> >> time anyway (which is effectively single threaded).
> >
> > Not that true
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:15:50 +0100
> We also can keep the old names as compatibility accessors for
> PowerPC only for a while, until everything is converted -- SPARC
> can do the same then. You can't really keep the old PowerPC names
> in
> All should converge on the same interface. That does not
> ab initio mean we should converge on what you currently
> have (although that might eventually be that case).
Well, Dave and I will happen to be in the same place in a few weeks for
LCA so we might spend some time having a look there
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the
> The kernel doesn't care if one CPU is in OF land while the others
> are doing other stuff -- well you have to make sure the OF won't
> try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
> I'm a bit concerned about the
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits,
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that "that's what the
current ports do"?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a
On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
>
> > We could of course have the interface work either on a copy of the tree
> > or on a real OF (though that means changing things like get_property on
> > powerpc and fixing the gazillions of users) but I tend to think that
> > working on
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
> > Except that none of the powerpc platforms can keep OF alive after the
> > kernel has booted, which is why we do an in-memory copy of the tree.
>
> Adding that functionality hasn't gotten easier at all since
> we use the flattened
On Tue, 2007-01-02 at 12:37 +0100, Segher Boessenkool wrote:
> >> So please do this crap right.
> >
> > I strongly agree. Nowadays, both powerpc and sparc use an in-memory
> > copy
> > of the tree (wether you use the flattened format during the trampoline
> > from OF runtime to the kernel or not
On Tue, 2007-01-02 at 12:45 +0100, Segher Boessenkool wrote:
> > In addition, I haven't given on the idea one day of actually merging
> > the
> > powerpc and sparc implementation of a lot of that stuff. Mostly the
> > device-tree accessors proper, the of_device/of_platform bits etc...
> > into
>
Benjamin Herrenschmidt wrote:
This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.
I don't agree. It's definitely not clear to me
* Segher Boessenkool <[EMAIL PROTECTED]> [070102 12:37]:
> Are you really suggesting that using a kernel copy of the
> device tree is the correct thing to do, and the only correct
> thing to do -- with the sole argument that "that's what the
> current ports do"?
There might also be a speed
Simple system tools should not need to interpret binary data in
order to provide access to simple structured data like this, that's
just stupid.
I would agree with you if the data was properly typed in the first
place
but it's not,
OF device tree properties are "properly typed" just fine --
IMHO, the directory entries in the filesystem
should be in the form "[EMAIL PROTECTED]" (eg: /[EMAIL PROTECTED],0,
"pci" is the node name, "@" is the separator character defined
by IEEE 1275, and "1f,0" is the unit-address,
which are always guaranteed to be unique.
They should be. The problem
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for everything, heh.
We have well defined interfaces to access that
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something like drivers/of1394 maybe.
1394? :-)
Thus if i386 is going to
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices
There is one big problem: text representation is useless
(to scripts etc.) unless it can be transformed back to binary;
i.e., it has to be possible to reliably detect _how_ some
property is represented into text, something that cannot be
done with how openpromfs handles it.
Text is text is text
It has proved a good idea in general as I can easily get an exact
device-tree dump from users by asking for a tarball of
/proc/device-tree
and in some case, the data in there -is- binary (For example, the EDID
properties for monitors left by video drivers, or things like that).
Yes and with
It has proved a good idea in general as I can easily get an exact
device-tree dump from users by asking for a tarball of
/proc/device-tree
and in some case, the data in there -is- binary (For example, the EDID
properties for monitors left by video drivers, or things like that).
Yes and with
There is one big problem: text representation is useless
(to scripts etc.) unless it can be transformed back to binary;
i.e., it has to be possible to reliably detect _how_ some
property is represented into text, something that cannot be
done with how openpromfs handles it.
Text is text is text
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something like drivers/of1394 maybe.
1394? :-)
Thus if i386 is going to
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for everything, heh.
We have well defined interfaces to access that
IMHO, the directory entries in the filesystem
should be in the form [EMAIL PROTECTED] (eg: /[EMAIL PROTECTED],0,
pci is the node name, @ is the separator character defined
by IEEE 1275, and 1f,0 is the unit-address,
which are always guaranteed to be unique.
They should be. The problem is buggy
Simple system tools should not need to interpret binary data in
order to provide access to simple structured data like this, that's
just stupid.
I would agree with you if the data was properly typed in the first
place
but it's not,
OF device tree properties are properly typed just fine --
* Segher Boessenkool [EMAIL PROTECTED] [070102 12:37]:
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that that's what the
current ports do?
There might also be a speed advantage if
Benjamin Herrenschmidt wrote:
This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.
I don't agree. It's definitely not clear to me
On Tue, 2007-01-02 at 12:45 +0100, Segher Boessenkool wrote:
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something
On Tue, 2007-01-02 at 12:37 +0100, Segher Boessenkool wrote:
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for
On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that that's what the
current ports do?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a good
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
I'm a bit concerned about the
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF
All should converge on the same interface. That does not
ab initio mean we should converge on what you currently
have (although that might eventually be that case).
Well, Dave and I will happen to be in the same place in a few weeks for
LCA so we might spend some time having a look there if
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:15:50 +0100
We also can keep the old names as compatibility accessors for
PowerPC only for a while, until everything is converted -- SPARC
can do the same then. You can't really keep the old PowerPC names
in kernel-wide code
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:28:21 +0100
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:37:32 +0100
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:40:17 +0100
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
The biggest problem is the huge collection of workarounds we have
for PowerPC alone already -- if that can be moved into some
quirk collection thing, where certain quirks are only run on some
systems, it might scale.
Well, if you notice, I've been moving most of such workarounds to
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, fix
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree
On Jan 3 2007 01:52, Segher Boessenkool wrote:
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Wed, 3 Jan 2007 01:48:02 +0100
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Wed, 3 Jan 2007 01:52:06 +0100
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Wed, 3 Jan 2007 02:14:34 +0100
[snipping a bit for now]
and then, fix
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree fs. I thought the plan was
to
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Wed, 3 Jan 2007 02:13:39 +0100 (MET)
On Jan 3 2007 01:52, Segher Boessenkool wrote:
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 16:09:14 +1100
> Probably. The question now is that if we want to somewhat converge, what
> to do... either change sparc habits or change powerpc habits :-) I'll
> let that fight happen between you and paulus and watch while
On Mon, 2007-01-01 at 21:01 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 02 Jan 2007 15:57:05 +1100
>
> > I like being able to have a simple way (ie. tar /proc/device-tree) to
> > tell user to send me their DT and have in the end an exact binary
> >
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:57:05 +1100
> I like being able to have a simple way (ie. tar /proc/device-tree) to
> tell user to send me their DT and have in the end an exact binary
> representation so I can actually dig for problems, like a wrong
> I think there is high value in an OFW filesystem representation
> that gives you _EXACTLY_ what the OFW command line prompt does
> when you try to traverse the device tree from there, and that
> is what openpromfs tries to do.
Except that every OFW implementation I have here shows you
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:05:59 +1100
> It has proved a good idea in general as I can easily get an exact
> device-tree dump from users by asking for a tarball of /proc/device-tree
> and in some case, the data in there -is- binary (For example, the
> The filesystem bit is for groveling around and getting information
> from the shell prompt, or shell scripts. Text processing.
>
> If you want the binary bits, export it with something like
> /dev/openprom. We don't generally export binary representation
> files out of /proc or /sys, in fact
On Sun, 2006-12-31 at 19:37 -0800, David Kahn wrote:
> Folks,
>
> If we reused the current code in fs/proc/proc_devtree.c
> and re-wrote the underlying of_* routines for i386 only,
> (in the hope of removing the complexity not needed for
> this implementation) would that be an acceptable
>
1 - 100 of 177 matches
Mail list logo
