(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). > 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. -- Tanu
