Any interest in swat enhancement

[John E. Malmberg]

"Andrew Tridgell" <tridge#linuxcare.com> wrote:

> I have a cunning plan for a change in the internals of Samba that will
> make this sort of option easy (changing the debug level on an
> individual process etc)
>
> The plan is to get rid of the current ad-hoc UDP messaging used for
> the oplock implementation and instead add a generic messaging layer to
> smbd and nmbd. A tdb would be used to store a queue of messages for
> each process and the smbd would check this queue when a signal is
> received.

Would not a pipe to the process have the effect of queuing up the small
messages?  Or is the problem that you can not asynchronously write to a
pipe?

[Please remember that I am not a Unix system level person]

> We then rip out all the udp messaging code in oplock.c and instead do
> something like:
>
>   message_send(pid, MSG_OPLOCK, (void *)&some_struct,
sizeof(some_struct));

Then would the routine that was signaled then call the tdb routines to find
out the message, or would it call:

num_bytes = message_recv(&pid, &msg_code, (void *)bufptr,
sizeof(some_struct));


> I mainly want to put this in place because I don't like the current
> use of UDP for this (apart from the denial of service possibilities it
> is just ugly!)

The degree of signal emulation on NON-UNIX systems may be make this
interesting to implement.

Wrapping the message retrieval from the tdb may allow you to explore other
options with out having to change to much source each time.

> As a side effect we can add a MSG_DEBUG option that allows the debug
> level to be set. Similarly for messages that allow the config file
> to be re-loaded, connections dropped, oplocks broken etc.

It seems like the logical step would be to store the smb.conf file in a tdb,
and have a program that could read an existing smb.conf file into it.  Of
course there would also need to be a way to convert the tdb back into a
human readable smb.conf as a dump.

> I know tdb isn't the ideal mechanism for this (doing a queue with tdb
> is ugly) but it seems like the best option available to us.

I am still finishing up on 2.0.6, so I have not had a chance yet to look at
the tdb stuff.

Any chance that your tdb could reside in a shared memory area since the
amount of information that it would need to queue up should not be that
large.

This communication method would assume that the sender and the receiver were
on the same system of course.

-John
wb8tyw at qsl.network