On Sat, Nov 29, 2008 at 12:01:54PM +0200, Vesa Jääskeläinen wrote:
> Robert Millan wrote:
> > On Tue, Nov 25, 2008 at 10:17:17PM +0100, Yoshinori K. Okuji wrote:
> >> On Saturday 22 November 2008 16:35:09 Robert Millan wrote:
> >>> When an error is detected by ata.mod during drive scan, it will pass it to
> >>> the upper layer. This results in GRUB aborting when trying to enter
> >>> normal
> >>> mode, even if the error is not critical (e.g. affects a drive not used
> >>> during boot).
> >>>
> >>> There are a number of places in ata.mod where these errors could be
> >>> handled, so I'm not sure if my proposed change would be the best
> >>> approach.
> >>> Some comment would be appreciated.
> >> This is one way, but I think the upper layer should be more robust against
> >> errors raised from modules. For example, we can unload a module, and clear
> >> GRUB_ERRNO, if the init function in this module return an error.
> >
> > But if the error is specific to a device unit, unloading the module would
> > result in all units of this device class being disabled, which is most
> > likely
> > not what we want.
> >
>
> Perhaps this should then be handled on generic code performing the scan?
>
> Just give unique error type and just ignore the error (or dump it to
> screen) and continue to next device/operation.
What do you mean generic code? It's all in ata.mod:
- grub_ata_initialize () invokes grub_pci_iterate (grub_ata_pciinit)
- grub_ata_pciinit () runs grub_ata_device_initialize () on a few
prospective device units
- grub_ata_device_initialize () might return with grub_errno != 0
or you mean in grub_ata_pciiinit() ?
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
