[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120515153614.4b5b4525@pyramind.ukuu.org.uk>
Date: Tue, 15 May 2012 15:36:14 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Gleb Natapov <gleb@...hat.com>
Cc: Hannes Reinecke <hare@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH] EDD: Check for correct EDD 3.0 length
On Tue, 15 May 2012 17:21:29 +0300
Gleb Natapov <gleb@...hat.com> wrote:
> On Tue, May 15, 2012 at 03:18:49PM +0100, Alan Cox wrote:
> > On Tue, 15 May 2012 17:12:14 +0300
> > Gleb Natapov <gleb@...hat.com> wrote:
> >
> > > On Tue, May 15, 2012 at 02:49:45PM +0100, Alan Cox wrote:
> > > > > I do not see support for other spec to be important, but you are welcome
> > > > > to write support for it if you need it. The only way I see to check what
> > > > > spec edd info corresponds to is to calculate checksum according to both
> > > > > specs and see which one succeeds.
> > > >
> > > > No it doesn't work like that. This is a regression for existing working
> > > > systems. It needs to be reverted or fixed. If it was a new feature you'd
> > > > have a point - but it isn't. You've broken stuff, undo the breakage.
> > > >
> > > Code never supported anything but EDD4.0 spec. I checked history git.
> > > Code erroneously tried to interpret EDD3.0 info according to EDD4.0 spec
> > > providing garbage as a result.
> >
> > Providing some valid data and info, which has now disappeared.
> >
> False. See my other mail:
>
> # cat /sys/firmware/edd/int13_dev80/interface
> SCSI id: 0 lun: 1224979098644774912
>
> This is what I got on my system. How is it useful?
Sample case of .. 1
Have you checked how the various distribution grub installers and the
like respond to the various changes or having bits of their edd data
vanish mysteriously ?
It's been this way for a long time, there is no rush to fix it. So we
should fix it properly not break stuff.
Actual systems in the field are using both 3.0 and 4.0 so we need to deal
with that as part of fixing this. That is the reality of the situation.
1.1 I suspect we can not care about.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists