(Q asked by a colleague, a wee bit vague on details so i'm hoping
i'm describing it correctly, seems like it should be easy to solve.)
short form of question: what is the standard way of, at boot time,
passing the kernel information to specify that a built-in driver
should *not* be started?
longer form of question: target system has two "slots", each of
which contains a distinct embedded system running linux. both of those
systems run the same kernel, *except* that, in slot 0, kernel should
start and run a particular driver whereas, in slot 1, the kernel
should *not* start that particular driver, whereupon apps on that
system will fall back and do things differently. (apparently, the apps
will use the simple existence of the driver's /dev/driver special
device file to identify which approach to take.)
as i understand it, then, whether or not that driver should start is
based simply on being able to identify the slot the board is in, and
this is something that is allegedly available to u-boot, which will
then pass the appropriate info on the kernel command line, telling the
kernel whether or not to start that driver. so far, so good.
question is, what is the "appropriate" info to pass to the kernel to
identify whether or not to start a (built-in) driver? my initial
reaction was, define a simple module parameter, say "run", which is
tested immediately upon driver startup, and if it's "0", just exit;
otherwise, run normally. and then u-boot would add to the boot line:
... drivername.run=0 ...
am i overthinking this? i'm used to module parameters being used to
pass info to drivers and modules to *customize* their behaviour, not
to simply say whether to run or not.
is this a reasonable way to do this? is there a better/standard way?
and is there a simple example of that in the current kernel source?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
