From: Jonathan Nieder <jrnieder@gmail.com>
To: Erik Faye-Lund <kusmabite@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, msysgit@googlegroups.com, j6t@kdbg.org,
avarab@gmail.com, sunshine@sunshineco.com
Subject: Re: [PATCH v4 15/15] daemon: opt-out on features that require posix
Date: Mon, 18 Oct 2010 11:31:34 -0500 [thread overview]
Message-ID: <20101018163134.GA6343@burratino> (raw)
In-Reply-To: <AANLkTim0KeW3eDHAsxrxMCvBUD_15R3VSrHSzOFq38A1@mail.gmail.com>
Hi,
A response to the general questions.
Erik Faye-Lund wrote:
> On Fri, Oct 15, 2010 at 11:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Why does the signature even have to be different between the two to begin
>> with? I _think_ you have gid_t over there
>
> We don't, so this is the primary reason.
Just to throw an idea out: you can also do something like
#ifndef NO_POSIX_GOODIES
struct credentials {
};
#else
struct credentials {
struct passwd *pass;
gid_t gid;
}
#endif
and pass a pointer to credentials around.
> But also avoiding
> compilation-warnings is a secondary motivation.
(void) gid;
works for this.
> We do, so this becomes a bit of a hypothetical question. But would you
> seriously consider pretending to have a posix-feature less ugly than
> inlining a function that is only used once?
In general, yes.
Long functions can make code much, much more difficult to read. A
fake posix feature just requires some suspension of disbelief.
In this case (#ifdef-heavy main() vs opaque struct passwd), both
strike me as ugly.
> (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.
Sometimes the best abstraction is the posix one and sometimes not. I
don't think this would contradict with your planned patches, unless
they introduce #ifdefs all over the place.
>> 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?
(See linux-2.6.git:Documentation/SubmittingPatches, section "#ifdefs
are ugly".)
The ideal: never an #ifdef within a function. (Well, the ideal is
no #ifdef-s in .c files, but that's harder to take seriously.)
#ifndef HAVE_POSIX_GOODIES
static int drop_privileges(...)
{
return error("--user and --group not supported on this platform");
}
#endif
static int drop_privileges(...)
{
...
do
something
...
}
#endif
would make serve() look like
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
if (want to drop privileges) {
if (drop_privileges(...))
return -1;
}
return service_loop(socknum, socklist);
}
which should be quite readable even to a person only interested in the
!HAVE_POSIX_GOODIES case imho. With some code rearrangement it could
be made nicer. Now compare:
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
#ifdef HAVE_POSIX_GOODIES
...
do
things
...
#endif
return service_loop(socknum, socklist);
}
Just my two cents. Sorry I do not have something more substantive to
say.
next prev parent reply other threads:[~2010-10-18 16:35 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-11 21:50 [PATCH v4 00/15] daemon-win32 Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 01/15] mingw: add network-wrappers for daemon Erik Faye-Lund
2010-10-11 22:07 ` Jonathan Nieder
2010-10-11 21:50 ` [PATCH v4 02/15] mingw: implement syslog Erik Faye-Lund
2010-10-11 22:11 ` Jonathan Nieder
2010-10-11 22:28 ` Erik Faye-Lund
2010-10-11 22:37 ` Jonathan Nieder
2010-10-13 12:36 ` Erik Faye-Lund
2010-10-13 19:23 ` Eric Sunshine
2010-10-13 21:17 ` [msysGit] " Pat Thoyts
2010-10-14 0:47 ` Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 03/15] compat: add inet_pton and inet_ntop prototypes Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 04/15] inet_ntop: fix a couple of old-style decls Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 05/15] mingw: use real pid Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 06/15] mingw: support waitpid with pid > 0 and WNOHANG Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 07/15] mingw: add kill emulation Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 08/15] daemon: use run-command api for async serving Erik Faye-Lund
2010-10-13 22:47 ` Junio C Hamano
2010-10-14 10:18 ` Erik Faye-Lund
2010-10-17 4:43 ` Junio C Hamano
2010-10-11 21:50 ` [PATCH v4 09/15] daemon: use full buffered mode for stderr Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 10/15] Improve the mingw getaddrinfo stub to handle more use cases Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 11/15] daemon: report connection from root-process Erik Faye-Lund
2010-10-13 22:55 ` Junio C Hamano
2010-10-14 10:50 ` Erik Faye-Lund
2010-10-17 4:43 ` Junio C Hamano
2010-10-17 10:18 ` Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 12/15] mingw: import poll-emulation from gnulib Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 13/15] mingw: use " Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 14/15] daemon: use socklen_t Erik Faye-Lund
2010-10-11 21:50 ` [PATCH v4 15/15] daemon: opt-out on features that require posix Erik Faye-Lund
2010-10-13 23:02 ` Junio C Hamano
2010-10-14 11:02 ` Erik Faye-Lund
2010-10-15 21:16 ` Junio C Hamano
2010-10-18 12:05 ` Erik Faye-Lund
2010-10-18 16:31 ` Jonathan Nieder [this message]
2010-10-18 18:13 ` Andreas Schwab
2010-10-18 18:42 ` empty structs Jonathan Nieder
2010-10-21 21:16 ` [PATCH v4 15/15] daemon: opt-out on features that require posix Erik Faye-Lund
2010-10-21 22:00 ` Erik Faye-Lund
2010-10-21 22:03 ` Jonathan Nieder
2010-10-21 22:04 ` Erik Faye-Lund
2010-10-21 23:17 ` Junio C Hamano
2010-10-18 19:26 ` Junio C Hamano
2010-10-21 20:37 ` Erik Faye-Lund
2010-10-21 20:39 ` Jonathan Nieder
2010-10-21 20:54 ` Erik Faye-Lund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101018163134.GA6343@burratino \
--to=jrnieder@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=kusmabite@gmail.com \
--cc=msysgit@googlegroups.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).