On 01.10.2012 11:28, Tanu Kaskinen wrote:
> (Resending with non-empty subject, sorry for the hassle.)
>
> (And sorry for breaking threading, but I don't have the original message in
> my mailbox, so this is copied from an archive.)
>
> Juho Hämäläinen wrote:
>> Hello,
>>
>> There is some discussion about /etc/boardname specification here:
>>
>> http://lists.meego.com/pipermail/meego-architecture/2011-June/000171.html
>> http://www.mail-archive.com/meego-porting-VVXm0OgCXj10cC2WI2GV6A <at>
>> public.gmane.org/msg00095.html
>
> The second link returns 404.
>
>> But still I think there are some corners not covered. For one thing,
>> "field" count for different hardware is ambiguous due to replacing all
>> non-printing chars and otherwise deemed not-ok chars with '_' and at the
>> same time using '_' for combining different parts of the boardname string.
>
> Is it specified somewhere that applications can assume something about
> the field count? Is there even a specification that says that there is a
> concept of "fields" in the first place? There certainly is code that
> assumes that the boardname contains fields, separated by '_', but in
> order to make the assumption valid, it would be nice to have a man page
> or just documentation for the getboardname() function in boardname.h
> (currently there's zero documentation for the function).
Yep, there is no documentation, and the info I tried to gather was just
in the mailing lists, and nothing conclusive there either. The idea was
to come to some conclusion and document it with the boardname.
>> Now for example with N9 it's:
>> arm_nokia_rm_696_board_1601
>>
>> Snowball:
>> arm_calao_systems_snowball_platform_0000
>>
>> My Dell laptop:
>> ia32_dell_inc_02k3y4_a00
>>
>> VirtualBox:
>> ia32_ (explanation further down)
>>
>> So if you really want to parse something specific from the string it's a
>> bit cumbersome.
>>
>> I propose to change the field separator to something else than '_', I
>> vote for '-'. Anything that doesn't need to be escaped if used in file
>> name would be ok. Also field count should be constant in all cases,
>> since now BOARDNAME consists of variable count of information.
>>
>> On x86 boardname board_vendor and board_name are treated as different
>> information, those could be combined to get fixed three fields.
>>
>> Examples;
>>
>> Arch|Hardware |Revision
>> arm-nokia_rm_696_board-1601
>> arm-calao_systems_snowball_platform-0000
>> ia32-dell_inc_02k3y4-a00
>> ia32-virtualbox-1_2
>>
>> etc.
>>
>> One difficulty is VirtualBox, since it doesn't have the information used
>> in other x86 architectures
>> (/sys/devices/virtual/dmi/id/board_{vendor,name,version}). I'm not sure
>> if it's due to some module or other bit missing from the kernel, if
>> someone knows better it would be nice to know. Anyway,
>> /sys/devices/virtual/dmi/id/product_name and
>> /sys/devices/virtual/dmi/id/product_version contain useful data
>> ("VirtualBox" and "1.2", respectively), those could be used if
>> board_name is not found. Also, on the laptop product_* contain arguably
>> more sensible data than board_*, but it's probably different case with
>> nckd, for which the i32 boardname logic was probably originally written
>> for..
>>
>> At this point one important question is, are these changes even
>> sensible, or do you think the current implementation is good enough?
>> (not counting VirtualBox case, that needs some changes in any case)
>
> What's the problem that you're having? I'm only familiar with
> PulseAudio's use, I don't know where else /etc/boardname is being used
> (well, ohmd was mentioned in the discussion that you linked to). In
> PulseAudio's case, I think this would be a sufficient specification:
>
> The boardname is a 7-bit ASCII (UTF-8 could be specified too, if a
> larger character space is necessary) string, not containing null bytes.
> The string is divided into non-empty fields using '_' as the field
> separator. The fields are hierarchically ordered: the first field is the
> most generic one, and each successive field is a specifier for the
> previous hierarchy level.
>
> That specification would allow PulseAudio to load hw-specific
> configuration files, first trying a file name with the full boardname,
> and if the file is not found, keep trying more and more generic
> boardnames by removing the last field one by one.
This sounds good as well. But again, not-accepted chars or spaces or
whatever, if they are replaced, need to be replaced with someting else
than field separator. Having fixed field count is not that important,
but some sane way to discern different fields is.
My most important question was still the one I asked last,
>> At this point one important question is, are these changes even
>> sensible, or do you think the current implementation is good enough?
>> (not counting VirtualBox case, that needs some changes in any case)
That is, if and when boardname string is used somewhere, any changes to
the way the string is created will break those cases. I know of only
PulseAudio using this right now, policy/ohm has readyness to use
boardname, but currently there is just one generic configuration for
policy (that I know of).
[root@localhost ~]# rpm -q --whatrequires boardname
ohm-1.1.14-3.2.Nemo.armv7hl
So PulseAudio deps are broken for this atm as well. (PulseAudio doesn't
use boardname script directly, but uses /etc/boardname file which is
generated by boardname script)
Again, changing the way the boardname string is built is important only
if we see some benefit in it, I think having different levels of info
parseable is a good thing. Then, it's just fixing the places where
boardname is used, which may not be much, maybe just PulseAudio.
--
Juho
