libreplace on Linux was (Re: Changing back to per-thread credentials on Linux (fixing native AIO).)
obnox at samba.org
Thu Jun 28 09:19:05 MDT 2012
Jeremy Allison wrote:
> On Thu, Jun 28, 2012 at 09:39:03AM +0200, Jelmer Vernooij wrote:
> > Yes, let's not put utility code into libreplace. Originally we had a
> > bunch of portability wrappers scattered all over lib/; the goal of
> > libreplace was to split out the portability code from the
> > Samba-specific utility code and make sure that the rest of the code
> > didn't have to worry about portability as much rather than remember to
> > call e.g. sys_select().
> > From libreplace's README:
> > This subsystem ensures that we can always use a certain core set of
> > functions and types, that are either provided by the OS or by replacement
> > functions / definitions in this subsystem. The aim is to try to stick
> > to POSIX functions in here as much as possible. Convenience functions
> > that are available on no platform at all belong in other subsystems
> > (such as LIBUTIL).
> > Things in libreplace are standard POSIX, standard Linux or standard
> > BSD (strlcat and strlcpy only) APIs. On modern platforms it should be
> > empty.
> Well be careful what you wish for :-). Moving it out of
> libreplace and renaming the calls will make it a much more
> invasive patch, as it will have to touch many more subsystems
> (uidwrapper etc.) than it does otherwise.
> I originally designed it that way and moved to the libreplace
> idea to make the patch smaller.
I think both requests are reasonable.
I believe (because I don't know enough about libc internals to
really judge) that you can fix the issues with the syscall tricks.
And having a small patch is of course good.
The patches themselves look clean to me.
And the size of the patch using the libreplace approach is
really appealing, maybe too seductive.
But if design says it may not be done this way in libreplace,
then the patch needs to be bigger. Can we create an abstraction
layer where we can replace the standard setFOOid calls with the
special linux syscall variants? Something like vfs?
Or maybe it is sufficient to decide it at configure/compile time?
Cheers - Michael
> Anyway, I can move it back to the original design, but this
> is a blocker for me for many things I need to get done (and
> it needs to go into 3.6.next as well of course to fix the
> lost wakeup bug) so I'll make the changes and get it in
> once they're done.
> Thanks for the reviews.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 206 bytes
Desc: not available
More information about the samba-technical