Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Jean Delvare]

Hi Ivan,

On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> On 03/05/2015 09:46 AM, Jean Delvare wrote:
> > It's not just two tables (I don't expect a lot of BIOSes to provide two
> > tables in practice, and they would have essentially the same format
> > anyway) but more importantly two entry points. The _SM3_ entry point is
> > brand new and most applications (including dmidecode) don't support it
> > yet. It doesn't matter if the kernel itself can parse it, as it passes
> > the raw entry point to applications anyway.
> >
> > It happens that we are introducing this new sysfs raw interface at the
> > same time _SM3_ is being introduced, so we do not have to care about
> > backwards compatibility. Both the kernel and dmidecode will need to be
> > updated to support the new interface, so we can keep things simple and
> > let the kernel expose only the best entry point.
> >
> > If the sysfs raw interface was already present at the time _SM3_
> > support was being added, then we would have had to present both entry
> > points for backwards compatibility. And if some _SM4_ entry point is
> > ever added in the future with a new format, we will have to export it
> > as a new sysfs attribute so as to not break compatibility.
> >
> > As a summary, I agree that a single entry point file is OK for now, but
> > only because we are lucky that the timing is right.
> 
> Despite of timing is right.
> 
> The specification doesn't oblige firmware to provide two entry points.
> An implementation may provide either the 32-bit entry point or the 64-bit
> entry point, or both. For compatibility with existing SMBIOS parsers, an
> implementation should provide the 32-bit entry point, but it's not required.

I expect most implementations will do, as it's trivial to implement.

> Another case if specification requires to provide two entry points. Then 
> you can
> be sure in backward compatibility. But at least for now you can't.
> 
> It's obvious, if kernel found two entry points then it can create two 
> sysfs attributes.
> But, what kernel should do in case if only one new entry point is present.
> Generate entry point of old version..., sorry but it's bad idea. At 
> least because
> where guarantee that we have enough information for this. Only field we 
> can bring
> thought entry point versions is magic string _SM*_, and based on it, if util
> don't support new version it can warn. It's used for differ versions and
> there is nothing we can do more.

I agree that the kernel should not fake an entry point which does not
exist (I'm not sure if you misunderstood me but I never suggested that.)

-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/