On Wed, 14 Jul 2010 11:47:10 +0200, Piotr Jaroszyński wrote > On 14 July 2010 07:25, <[email protected]> wrote: > > From: Guo-Fu Tseng <[email protected]> > > > > Currently we do nothing while polling user input when shell banner > > waiting. I modified it to do something like in shell, scheduling > > processes while waiting for user input. > > This makes sense imho. > > On the other hand, I think the original issue remains because many > people run with shell banner disabled most of the time (I know I do). > > I was thinking about adding the extra net_steps to netdev_close. > Possibly with a facility to mark netdevs as still awaiting packets to > not wait blindly. > > -- > Best Regards > Piotr Jaroszyński
Agreed! It only solves some of the cases. Michael modified this patch, and makes it skip the waiting if user pressed a key that is not we are waiting for. If people want to skip it, it should be useful. And the code size could be smaller. The reason I make it to wait for full 2 seconds(Default value) is that I sometimes hit the wrong key, and failed to enter to shell. Anyway, just an idea. Both way works fine. Just don't know which way is preferred by most people. :) I do share the idea of polling extra packets when needed. But I don't want the program flow to act like this way. imho, net/netdevice.c:net_step() should only be called by core/process.c:step(). Piotr did mentioned that it is just an idea, and suggest that we can move the actual actions from net_step() to another function. And both netdev_close() , and net_step() can call that function. This does make the code flow less confusing, and easier to maintain. For the original design. We can assume that all the network receive flow(ex: netdevice->ipv4->tcp->app) is happened in ''netdevice process'', if we do the polling in netdev_close(), it'll break that assumption. It might not hurt a lot anyway. But this makes me think if there is a better way. On the other hand, the function name netdev_close() would make me think that it tries to nullify/free the resources. Instead of processing data. In some cases, the close() event DO wait for resources to be freed and safe to close. But I rare see a design that actually do the works in close(), and tries to make it possible to free the resources. It's just my point of view, suggestions are very welcome and appreciated. Guo-Fu Tseng _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
