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/[email protected]/msg00095.html
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.
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)
Regards,
Juho (jusa_)
