[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [RFC][PATCHv2] new applets: i2c-tools
From:       Xabier Oneca  --  xOneca <xoneca () gmail ! com>
Date:       2014-12-14 12:58:43
Message-ID: CACkgH71q=ven9DiYeUm8iXFAJbhZUZ1-er+LZRiaaGoD9OtzmQ () mail ! gmail ! com
[Download RAW message or body]

Hello,

2014-12-13 1:31 GMT+01:00 Isaac Dunham <ibid.ag@gmail.com>:
> On Fri, Dec 12, 2014 at 12:09:55AM +0100, Xabier Oneca -- xOneca wrote:
>> If you mistype 'i2cbus' parameter in the command line, you will have
>> both a warning and an error opening two devices, which can be
>> misleading.
>>
>> Why would you even try to open the old-style device in a new kernel,
>> or a new-style dev in an old one? I think this can be avoided with the
>> usual '#if LINUX_VERSION ...', be it with preprocessor instructions,
>> or with a plain 'if ... else' statement.
>
> This is the wrong way, IMHO.
> It means that you *cannot* compile busybox with i2ctools that work on
> pre-2.6.14(?) kernels, unless you build it using 2.6.14 or older headers;
> and in that case, you must recompile busybox if you upgrade the kernel.
> It would be tolerable if it were right at the 2.4/2.6 cutoff, but it
> isn't.
>
> Also, someone could configure a newer kernel to use the same layout for
> /dev as an older kernel in at least two ways:
> -if they use a static /dev
> -if they configure the hotplug helper to use the old layout (for
> example, for backwards compatability).
> In mdev, that might look like this:
> i2c-([0-9]*)    root:i2c        0660    =i2c/%1

That's reasonable... Didn't think on this.

> I would support checking both paths.

Makes sense. Indeed, if that's the way i2c-tools works...

Convinced! :)

Cheers,

Xabier Oneca_,,_
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]