I've taken the 'version' bit, modified is so:Good point...
2/ You can only change the setting when there are no active threads.
cool... thanks for thinking about this...
New version this part patch follows. It should be completely
compatible with your patch. from a user-space perspective.
Well at this point they are not needed since we
The 'port' bit I had trouble liking.
family proto proto addr port
to the 'ports' file.
'family' and 'addr' are completely ignored.
'port' is effectively ignored (value is stored in a variable whichI'm not sure I understand this... nfsd_port is set and used in
Maybe being the author of these interfaces you have a better perspective
That leaves 'proto' and 'proto'. One should be 'tcp' or 'notcp', the
other should be 'udp' or 'noudp'. Which is which? Udp comes first,
but it isn't at all obvious from the interface..
I think you should write:Understood... And I'll assume the default of both TCP and UDP
[+-]family proto addr port
and every field must be checked and used.
So while we only support ipv4, the 'family' must by 'ipv4' or an error
'+' adds an endpoint. '-' removes it.
Won't this break backwards compatibility with all the 2.4 kernels?
The old nfssvc syscall should add 'ipv4 udp * %port' and 'ipv4 tcp *
%port' if they don't already exist.
Maybe I'm missing something here.... but I'm not quite sure how passing
An alternate interface, which would be quite appealing, would be to
require the user-space program to create and bind a socket and then
communicate it to the kernel, possibly by writing a file-descriptor
number to a file in the nfsd filesystem.
'nfsd' would check it is an appropriate type of socket, take
an extra reference, and use it.
This would probably be best done *after* the nfsd threads were
started, so there would need to be a way to start threads without
them automatically opening sockets. I'm not sure what the best
interface for that would be... Maybe establishing sockets before the
thread would be ok.