[gPXE-devel] [PATCHv2 4/6] [core] Keep scheduling while shell banner waiting

[Guo-Fu Tseng]

On Wed, 14 Jul 2010 11:47:10 +0200, Piotr Jaroszyński wrote
> On 14 July 2010 07:25,  <cooldavid at cooldavid.org> wrote:
> > From: Guo-Fu Tseng <cooldavid at cooldavid.org>
> >
> > 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