Re: [PATCH] (ata.mod) avoid passing grub_errno to upper layer

[Robert Millan]

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."