Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v4 15/15] daemon: opt-out on features that require posix

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:48

Erik Faye-Lund [off-list ref] writes:
(I'm going a little off-topic here, I hope that's OK)
I'm not too happy with some of the pretend-really-hard-to-be-posix-magic
around in the Windows-port. In fact, I have some patches to reduce
posixness in some areas, while getting rid of some code in
mingw.c. Would such patches be welcome, or is pretend-to-be-posix the
governing portability approach? In some cases, this comes at the expense
of some performance (and quite a bit of added cludge), which is a bit
contradictory to the Git design IMO.
If the part of the codepath you need to make conditional can be better
helped by abstraction that is higher-level than POSIX, that would be a
very acceptable approach.  The "struct credential" idea Jonathan gave you
is an example of such.  The goal is not to force POSIX on Windows or make
POSIX emulation on Windows more complete---that is not git's job.  Just
that in most of the case the level of abstraction POSIX gives has been
adequate for our codebase.
quoted
This is especially
true if you are making the "drop-privileges" part a helper function, no?
I don't follow this part. What exactly becomes more true by having a
drop-privileges function?
By using a bit higher level abstraction than POSIX primitives give you
(e.g. initgroups(), setgid(), etc.) that does not have to depend on
particular POSIX implementation details (e.g. "struct passwd", gid_t,
etc.), you can make the main codepath cleaner and free of ifdefs.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help