All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.