Re: proc_generic - cool new stuff

Rob Riggs (rriggs@tesser.com)
Wed, 06 Nov 1996 23:53:19 -0700 (MST)


On 07-Nov-96 alan@lxorguk.ukuu.org.uk wrote:
>>> therefore must be OK to sleep in. It definitely cannot use cli/sti
>> to lock it's tables. Anything still relying on cli/sti will need
>> to be cached. (And hopefully some of these will be fixed by Keith
>> Owens soon.)
>
>You mean like the routing tables. We cannot sleep in the routing handling
>end of story. The current code just builds a kernel buffer, unlocks and
>feeds that out. That should work fine with your changes

I don't understand. In my code, when operating in non-cached
mode, proc_write() is not buffered, but writes directly into the
user buffer. This may require the kernel to swap, right? (Which
means we sleep, right?). So, what we _really_ need is buffered,
non-cached operation. OK... I think I finally get it.

I can be really dense sometimes :)

>> will keep the proc data consistent (no missing or duplicate data),
>> as was the original intent of the caching model.
>>
>> The included patch should apply cleanly to 2.1.7.
>>
>> Comments?
>
>Bonus points for being able to select() on a /proc file and wake when
>it changes ;)

Well, select() works with the new proc fifos. It is easy to code
a simple proc_notify() that would wake up the select()ed files.

First, take out the S_ISFIFO() check in the proc_g_select() code and
then add the following to proc_fs.h:

extern inline void proc_notify(struct proc_dir_entry *pde)
{
wake_up_interruptible(&(pde->wait_q));
}

Now in the kernel (using /proc/net/route as an example), remove
'static' in the definition of proc_net_route and declare it in
net/route.h. Then call proc_notify(&proc_route_net) after every
routing table change... viola - any code waiting in select() for
that file wakes up.

Actually, what we need is a P_CANSELECT flag. That way select will
only work on proc files that support it.

Rob
(rriggs@tesser.com)