Hi Wolfgang, On Tue, Dec 11, 2012 at 4:39 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Hatim Ali, > > In message <1355223289-15685-5-git-send-email-hatim...@samsung.com> you wrote: >> From: Akshay Saraswat <aksha...@samsung.com> >> >> Adding a generic polling function to continuously monitor events and >> trigger actions corresponding to them. >> >> Signed-off-by: Akshay Saraswat <aksha...@samsung.com> >> Acked-by: Simon Glass <s...@chromium.org> >> >> diff --git a/README b/README >> index 037513a..0e4083c 100644 >> --- a/README >> +++ b/README >> @@ -2841,6 +2841,13 @@ Configuration Settings: >> the application (usually a Linux kernel) when it is >> booted >> >> +- CONFIG_BOARD_POLL >> + There are various scenarios in which parallel-thread like >> + polling is required to monitor status of variety of devices. >> + For such situations CONFIG_BOARD_POLL shall be enabled >> + and funtion call board_poll_devices() from console_tstc() >> + will then poll for the device status as defined inside function. > > > Sorry, but I dislike this, for a number of reasons. > > 1) There is, and has always been, a very basic design decision, that > U-Boot is strictly single-tasking, i. e. we don't have any kind of > "background activities" goind on. Your introduction of a device > polling mechanism violates this principle. > > I don't say that this is unacceptable, but we have to be aware that > this is a far-reaching decision, so we should consider it very > carefully. > > If anything like this gets implemented, it has to be done in a way > that will be general enough to be useful to others as well.
Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input. I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this. > > 2) U-Boot is a boot loader, not an OS. Do we really need continuous > temperature management in U-Boot? I think not. After all, our > main purpose is to boot an OS, and do that as fast as possible. > The majority of users will see U-Boot running only for a few > milliseconds, and only when they boot the device - which may be > very seldom. > > So what exactly do we need this for? It is possible that the OS cannot be found or is corrupted due to some sort of failure or error. In that case we may need to prompt the user to insert media that can be used to recover the device. If the secure boot is turned off, we may want to print a warning and require that the user confirm. In both cases, we can be in U-Boot for a while. By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds. > > 3) Your hooking of a device polling into console_tstc() is broken by > design. It may be sufficient for the specific use case you have > in mind here, but it is totally useless for any other purpose. > > This needs a lot of additional thought, and major changes to the > implementation. Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console. Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Without facts, the decision cannot be made logically. You must rely > on your human intuition. > -- Spock, "Assignment: Earth", stardate unknown > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
