grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open Firmware: search devalias children for disks


From: Marco Gerards
Subject: Re: Open Firmware: search devalias children for disks
Date: Wed, 01 Sep 2004 09:05:43 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

> The current Open Firmware code only examines the devaliases when
> searching for disks present. (In general we probably want to search
> the whole device tree, but this behavior is ok for now.)

The best behavior would be:

1) Look up all devaliases.
2) Look up all nodes in the tree that do not have a valid devalias.

What do you think about that?

> However when SCSI disks are present, the devalias is to the SCSI
> controller node, and under that are the block- and byte-oriented
> devices sd and st. Example:
>       /bandit/gc/53c94
>               /address@hidden,0
>               /address@hidden,0
>
> This patch (for comment only right now) allows grub2 to consider the
> children of devaliases when looking for disks, which lets it find the
> sd node above.

That is nice.

> grub_ofdisk_open() was modified to avoid resolving aliases by hand;
> OF's open and finddevice do it for us. Also the error checking it was
> doing was a little off.

That is even better.  I am just not sure if that will work everywhere,
I will test that too.

> However, note that I had to comment out the ":0" being appended to the
> device path (e.g. "scsi/sd:0"). I'm still not sure why, but when the
> ":0" was present, open and close on the block device would succeed but
> seek failed. :( More investigation may be needed, as I *think* the
> stage1 loader loaded grubof using ":0" in the device name (as seen in
> /chosen/bootpath). But with this patch on top of all the other patches
> I've sent so far, I get the following output:

How was it added?  By tab completion?

I wonder what the ":0" means?  A partition?  The last used partition
or so.  I think I can look this up.

> grub> ls
> (scsi/sd) (scsi/sd,0) (scsi/sd,1) (scsi/sd,2) (scsi/sd,3) (scsi/sd,4)
> (scsi/sd,5)
> grub> ls (scsi/sd,5)/
> lost+found/ dev/ etc/ tmp/ var/ proc/ bin/ boot/ home/ lib/ mnt/ opt/
> root/ sbin/ usr/ halt
>
> That's pretty good. :)

Absolutely!  Have you tested the linux loader, BTW?

--
Marco





reply via email to

[Prev in Thread] Current Thread [Next in Thread]