DSDT in initrd?

DSDT in initrd?

[Markus Gaugusch]

Has anybody thought about putting the dsdt into the initial ramdisk?
This would make changing/updating it much easier.

Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Markus Gaugusch]

> > Has anybody thought about putting the dsdt into the initial ramdisk?
> > This would make changing/updating it much easier.
> I guess initrd is too late to override it...
If I would mount it, probably yes. But I rather thought about the way that
bootsplash uses: Scan the initrd for a magic signature and read it 'raw'.
The dsdt would not be in the filesystem of the initrd, but just appended
to the compressed initrd. I think that something that is early enough for
bootsplash should be early enough for the dsdt as well.

Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Bob Lees]

Why use initrd?  Why not allow a file name to be passed to the kernel at boot 
a la acpi=off, acpi=mydst.hex or whatever?  Put the file in the /boot 
directory?

Just my two pennies worth

Bob

On Monday 05 May 2003 07:39, Markus Gaugusch wrote:
> > > Has anybody thought about putting the dsdt into the initial ramdisk?
> > > This would make changing/updating it much easier.
> >
> > I guess initrd is too late to override it...
>
> If I would mount it, probably yes. But I rather thought about the way that
> bootsplash uses: Scan the initrd for a magic signature and read it 'raw'.
> The dsdt would not be in the filesystem of the initrd, but just appended
> to the compressed initrd. I think that something that is early enough for
> bootsplash should be early enough for the dsdt as well.
>
> Markus

-- 
Bob Lees
Diamond Consulting Services Ltd
Aylesbury, Bucks, HP17 8UG
Phone: +44 (0) 1296 747667
Fax: +44 (0) 1296 747557
email: bob-l+PWtdWbHAsG2Il/BtU0GPXRex20P6io@public.gmane.org




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Christian Zoz]

On Mon, May 05, Markus Gaugusch wrote:
> > > Has anybody thought about putting the dsdt into the initial ramdisk?
> > > This would make changing/updating it much easier.
> > I guess initrd is too late to override it...
> If I would mount it, probably yes. But I rather thought about the way that
> bootsplash uses: Scan the initrd for a magic signature and read it 'raw'.
> The dsdt would not be in the filesystem of the initrd, but just appended
> to the compressed initrd. I think that something that is early enough for
> bootsplash should be early enough for the dsdt as well.

And this would make patching dsdt much easier for the unexperienced
user. Just download a file and call 'mkinitrd'.

If bootsplash is early enough, then lets do that.

-- 

ciao, christian

  --------------------------------------------------------------------
    Verglichen mit jedem x-beliebigen Redmonder Betriebssystem-Clone
    ist Linux geradezu eine leuchtende Perle der Datensicherheit.
  ------ Frank Rennemann (http://www.linux-knowledge-portal.org) -----


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Markus Gaugusch]

On May 6, Bob Lees <bob-l+PWtdWbHAsG2Il/BtU0GPXRex20P6io@public.gmane.org> wrote:
> Why use initrd?  Why not allow a file name to be passed to the kernel at
> boot a la acpi=off, acpi=mydst.hex or whatever?  Put the file in the
> /boot directory?
I think that this is not possible. The filesystem would have to be
accessible which is not the case at the early stage where ACPI loads
(there could even be the case, that no interrupts are assigned yet, to use
the scsi controller where the partition with the file is stored). Not to
mention, that harddisk and scsi drivers are loaded much later anyway.
The initrd is the only sane way to do this. I could also change my patch
to accept a plain DSDT file, without my 'magic' signature, if no other
initrd data is present.

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Christian Zoz]

On Tue, May 06, Markus Gaugusch wrote:
> On May 6, Bob Lees <bob-l+PWtdWbHAsG2Il/BtU0GPXRex20P6io@public.gmane.org> wrote:
> > Why use initrd?  Why not allow a file name to be passed to the kernel at
> > boot a la acpi=off, acpi=mydst.hex or whatever?  Put the file in the
> > /boot directory?
> I think that this is not possible. The filesystem would have to be
> accessible which is not the case at the early stage where ACPI loads
> (there could even be the case, that no interrupts are assigned yet, to use
> the scsi controller where the partition with the file is stored). Not to
> mention, that harddisk and scsi drivers are loaded much later anyway.
> The initrd is the only sane way to do this. I could also change my patch
> to accept a plain DSDT file, without my 'magic' signature, if no other
> initrd data is present.

Grub should be able to handle the file access at this stage.

-- 

ciao, christian

  --------------------------------------------------------------------
    Verglichen mit jedem x-beliebigen Redmonder Betriebssystem-Clone
    ist Linux geradezu eine leuchtende Perle der Datensicherheit.
  ------ Frank Rennemann (http://www.linux-knowledge-portal.org) -----


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Markus Gaugusch]

On May 6, Christian Zoz <zoz-l3A5Bk7waGM@public.gmane.org> wrote:
> Grub should be able to handle the file access at this stage.
Not everybody is using Grub.

My patch works fine, although I think that I found some possible
improvements, but nothing important yet.

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Alexander Hoogerhuis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Markus Gaugusch <markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org> writes:

> On May 6, Bob Lees <bob-l+PWtdWbHAsG2Il/BtU0GPXRex20P6io@public.gmane.org> wrote:
> > Why use initrd?  Why not allow a file name to be passed to the kernel at
> > boot a la acpi=off, acpi=mydst.hex or whatever?  Put the file in the
> > /boot directory?
> I think that this is not possible. The filesystem would have to be
> accessible which is not the case at the early stage where ACPI loads
> (there could even be the case, that no interrupts are assigned yet, to use
> the scsi controller where the partition with the file is stored). Not to
> mention, that harddisk and scsi drivers are loaded much later anyway.
> The initrd is the only sane way to do this. I could also change my patch
> to accept a plain DSDT file, without my 'magic' signature, if no other
> initrd data is present.
> 

Or make the acpi=file.hex boot argument refer to a file within the
initrd image. Then its just a case of getting mkinitrd patched to look
for /boot/dsdt.hex by default, and letting the user specificy an
alternate DSDT by parameter and generating initrd's would be a simple.

mvh,
A
- -- 
Alexander Hoogerhuis                               | alexh-rpjHciJLgqZBDgjK7y7TUQ@public.gmane.org
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE+t20FCQ1pa+gRoggRAqGvAKCZ1Vj+UcYKaRc/mvjwPkO7SKNqgACfSc7H
O0FXhxPs9k0paJ0i2jUSZgA=
=c/nm
-----END PGP SIGNATURE-----


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Markus Gaugusch]

On May 6, Alexander Hoogerhuis <alexh-rpjHciJLgqZBDgjK7y7TUQ@public.gmane.org> wrote:
> Or make the acpi=file.hex boot argument refer to a file within the
> initrd image. Then its just a case of getting mkinitrd patched to look
> for /boot/dsdt.hex by default, and letting the user specificy an
> alternate DSDT by parameter and generating initrd's would be a simple.
I don't have the knowledge (yet) to mount the initrd. Usually, it is
mounted after everything is initialised, but not at the early stage where
ACPI is loaded. I don't even know if any filesystem drivers are present at
this stage.

Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: DSDT in initrd?

[Markus Gaugusch]

On May 8, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:

> I don't think that 'magic' signature is good idea. It seems fragile...
The initrd filesystem is usually compressed, isn't it? ("file initrd"
returns "gzipped compressed data" for me).

So most clear-text strings will be messed up, especially if they have the
length and structure of mine (several parts are twice in the string).

Also, SuSE (I think you had an @suse email some time ago?) uses the same
technique for the bootsplash, and I think that something used by a major
distributor has probably been reviewed by a few peopl.

The only additional things I could check, are the bytes following the
signature and check if their value is "DSDT" (which is a good idea and
should be done).

I don't know if any other sanity checks can be done, but the ACPI
code could should already do that part for me anyway?

Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com