Any interest in swat enhancement
tridge at linuxcare.com
Wed Sep 6 06:37:38 GMT 2000
> Would not a pipe to the process have the effect of queuing up the small
we need all Samba processes and client utils (eg. smbstatus) to be
able to send messages to any other part of the system. That would mean
N^2 pipes, or a central messaging process. We don't want either.
> Then would the routine that was signaled then call the tdb routines to find
> out the message, or would it call:
the message would be in the tdb. The messages are meant to be small
(no limit as such, but large messages will be a bit slow).
> Wrapping the message retrieval from the tdb may allow you to explore other
> options with out having to change to much source each time.
yes, obviously :)
> It seems like the logical step would be to store the smb.conf file
> in a tdb
What I plan on doing here is to cache the config file in a tdb and
open that tdb read only except when re-generating. This would make for
fast smb.conf reload which is a factor on some systems.
> 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'd rather keep the master file in the current format and use the
database only as a cache mechanism to avoid re-parsing on each
Where this won't work is if you have constructs like:
include = smb.conf.%m
in that case the cache would be disabled.
> 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
it already uses shared memory (via mmap) where possible.
> This communication method would assume that the sender and the receiver were
> on the same system of course.
yep. the tdb api would allow for remote access but I don't plan on
More information about the samba-technical