Re: qlimit

> Now I know why I didn't think of it.  the issue is that display.c is quite a
> separate module from console.c.  display.c doesn't know about netfs, and the
> virtual consoles, and the nodes.  It is stand-alone.  So far I have managed
> to keep it this way.

The notification path is part of the fs protocols, so the code that
implements it is not really independent of the fs node implementation.  But
you can keep it modular and still do it this way.  Just put the guts of
display_notice_changes and display_notice_file_changed (and the notify
stubs) into the fs module and genericize the interfaces a bit.  

> But I don't have much against the separate bucket and class for it.  Is
> there a good reason not to keep it the way it is, except thread utilization
> performance?

There aren't any other issues I can think of.  But changing it from a
situation where the common case switches to one thread and back to it vs
the common situation switches back and forth between two threads could be
significant in the cache penalty and so forth for extra switching.  (Of
course such things pale in comparison to issues like the pager thread
explosion.)

> BTW, the files are getting longer and longer :)  At some time it might make
> sense to split it up into several files, but until it has stabilized, it is
> simpler to deal with the way it is.  I also will have to find a place for
> the client library and the clients, but this can wait until the code is
> there.  Are the makefiles flexible enough to build it all in one directory?

The makefiles suck for that.  Maybe I will get around to cleaning them up.