Better late than never :-) I am back. I understand your concerns and can assure that use-mode code will do right. I changed wchan address from system wide cdev pointer to syscons private address. What else need to be done to get this checked in and/or will you do that or I can proceed myself? Thanks, Alexander. On 23.02.2008, at 2:29, Kostik Belousov wrote: > On Sat, Feb 23, 2008 at 01:01:59AM +0900, Alexander Nedotsukov wrote: >> >> On 22.02.2008, at 0:47, Kostik Belousov wrote: >> >>> On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov >>> wrote: >>>> Hi, >>>> >>>> May I ask to revisit this issue? To me ENXIO is not semantically >>>> correct in this particular case. It also turns out that doing >>>> workaround in userspace may not be that good as we used to think. I >>>> propose is to fix VT_WAITACTIVE so it simply wait for bound device >>>> activation. For my understanding this change should not have any >>>> impact on existing code. I also removed really strange console >>>> cleanup >>>> bit sticked in a long time ago (see ioctl() part). >>>> It will be nice to see this patch >>> >>> >>>> (successfully tested by our affected users) committed to all >>>> branches. >>>> >>>> Thanks, >>>> Alexander. >>> >>> I mostly agree with the patch, given it is tested. >>> >>> The first (not important) note is that change of the wait channel >>> from >>> the address of the private structure to the address of the cdev >>> could >>> cause more spurious wakeups then before. I expect you usermode >>> code to >>> deal with it properly. >> Do you know any potential wakeup()s around the kernel? I did not see >> any spurious wakeups myself nor user reported it so far. However they >> are not welcome so if it considered to be unsafe we can use address >> of >> cdev pointer (&SC_DEV()) which is private to syscons. > Nothing prevents any code in the the kernel from performing wakeup on > any wait channel. Due to tradition, wait channel is usually an address > of some data structure that is owned by the code performing wakeup. > I do not know of any other code that uses cdev address as wait > channel, > > The issue of spurious wakeup is not very important per se. I think > more > essential for the correct operation is the fact that when the user- > mode > code is executed, console may already be inactive (again). This is > quite > similar to the unintended wakeups. > > Does the code handle this ? If yes, I think it shall handle the > wakeups too without any additional actions. > > I underline that this is not an objection against the patch.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:29 UTC