For reasons unknown, cygwin decided to use our sockaddr_storage.
As it is redefined to sockaddr_in it'd cause compilation errors in
cygwin headers. Fixed by first patch, which uses a more git-related
name (can we claim rights for the symbol, being first to use it? :-)

For the other, probably unrelated, reasons, they decided to leave
declarations of DT_* macros in dirent.h without providing dirent->d_type.
This is what NO_DTYPE in the 0002-patch is all about.

And on top of that, they removed dirent->d_ino (or probably replaced
it by __ino32, if at all).
BTW, can we somehow avoid using d_ino? It is referenced only in fsck-object=
s.c
Anyway, to workaround this I put

  COMPAT_CFLAGS +=3D -Dd_ino=3D__ino32

It helps, but surely is not the solution.

P.S. For all you poor souls on Win2k, my config.mak contains:

  NO_MMAP =3D YesPlease
  NO_DTYPE =3D YesPlease
  COMPAT_CFLAGS +=3D -Dd_ino=3D__ino32

Just to make it work (at least it's enough for me, even the tests run...)

I actually forgot to look at the patch.

Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter

  +else

  But of course when this goes on, soon the gcc commandline will get
really awfully ugly. This is why something _like_ autoconf is a good
thing - you can just detect if the system headers provide the type and
#define it only when they don't.

  Of course, inserting the #define to some .h file might work; I'm not
sure if any of the relevant socket routines is permitted to be a macro
which could expand to something - but even then, it's probably not very
likely that it would break stuff in practice.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams
-

not you. Someone has done the job of detecting things for you.
It's just a fair amount of hard work badly done.
-

Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter

Huh? "Our"? See RFC 2553 and e.g.:

	http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html

You have no business meddling with this identifier except working around
platforms which do not support it, but then do not complain that things
break when the platforms actually start supporting it. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams
-

That will remind me to consult the specs first.
-

"They" probably would like to hear about any irregularities that are found.
"They" probably don't like it when people treat an open source project as
if it was some unresponsive proprietary enterprise which does not listen

I don't see how it could help since __ino32 is not actually filled in
with anything.  In fact, I'll rename the field to __invalid_ino32 to
make that clear.

cgf
(cygwin project lead)
-

Please, accept my appologies for the sarcasm in the original post.
Sometimes I get an impression of cygwin being not maintained at
all, and that, if not justifies my behavior, but at least is an attempt

But why keep the DT_-macros?! And why there is two fields
hinting at d_ino, and why there is 3 (!) "struct dirent"
definitions in dirent.h (sys/dirent.h)?
Some with different names (d_reserved?).
And if cygwin is aiming for posix, what would d_fd or d_version
be (Open Group Specs v6[1] mention only d_ino and d_name)?

[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
-

Hmm.  I thought we'd already dispelled the myth that cygwin is
unsupported in this very mailing list.  That is an odd impression given
the fact that you were complaining about behavior in a version of cygwin
which was released on Monday but, apology accepted.

If you want to see evidence of continual cygwin development, you can always
visit this page:  http://cygwin.com/snapshots/ .  This page has snapshots
of cygwin built from cvs.  We make these available so that people will check

The default entry (i.e., the one you get without defining
__INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the

Hmm.  On linux, my /usr/include/bits/dirent.h has a d_reclen field in
dirent.  I know what that is and what it is used for but it's not
mentioned, that I can see, in SUSv3.  But, since I don't see anything in
the description of dirent in SUSv3 which says that the must have only
the fields mentiond, that's ok.

In any event, we don't claim to be POSIX compatible.  We actually are
working for linux compatibility but this is one regrettable place where
Windows doesn't allow that.

I explained about the DT macros and why we dropped d_ino support in
another message.

Anyway, I understand why the DT macros would cause problems and I have
removed them from the current CVS.  I don't see why the existence of
extra fields in dirent or why other non-default definitions would
cause any problems other than the "Doctor, doctor, it hurts when I
do this" variety.

cgf
-

It was my first update since a long time (which BTW broke some


Maybe it'd be a good idea just to remove the definitions? Or, as
__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.
Would be less confusion and no chance of someone defining one of the



It is not the existance of the extra fields which cause problems. It
is an existance of fields, the names of which imply a functionality
they do not provide which causes problems. Why should I seeing __ino32
in an official header think: "it is never filled anyway, so I
shouldn't use it"?! Or what could "__invalid_d_ino" mean? If it is
invalid (as in "can't be used", why is it there at all?

-

Detailed bug reports are always welcome on the cygwin mailing list:
cygwin at cygwin dot com .  I should point out that the existence of
bugs in a product does not indicate a lack of support of the product,

I sincerely doubt that anyone in this mailing list wants to get into a
discussion of cygwin design.  If you really want to discuss this, the
cygwin mailing list is a much better place for that.

cgf
-

First of all, thanks for joining our discussion.  Being able to
hear from somebody from other project firsthand (not just listen
to somebody talking in his own changelogs and code comments, but
in actual e-mail exchange discussion) lets us put faces and
names to the entity "so far just one of the external projects to

I haven't looked at the proposed patch by Alex, so would not

I was wondering what the justification for keeping DT_* without
d_type myself.  What is the preferred resolution on this one
from your point of view?  I suspect removing d_type while
leaving DT_* was just a transient error and you would want to
remove DT_* as well, in which case the patch on this issue by

I think renaming __invalid_* makes sense.  I'll see how we would
work this around on the git side to make things more portable.



-

I only read this list sporadically but I have chimed in from time to time
when people were talking about cygwin.  For the most part, it seems like

Actually, I started adding DT_* macros at one point, in preparation for
adding d_type, and then got sidetracked.  Their existence is a real bug

There were two fields in the dirent struct.  One was the "real" d_ino
which was a 64-bit ino_t, __ino32 was a legacy field from a time when
inodes were 32 bits.  I had already renamed the d_ino to __invalid_d_ino
but I didn't think I had to rename __ino32, too, since it wasn't a
standard field and didn't think that anyone would be using it.  However,
it is now __invalid_ino32 (and will probably disappear entirely) in CVS.

I knew that there would be fallout from getting rid of d_ino but this
change has been a long time coming.  Previously, the inodes reported in
d_ino were different from the (correct) ones in st_ino and some
applications were understandbly confused by that fact.  Making d_ino
accurate would have meant that we'd have to open every file in readdir
to get the windows equivalent of inode information and, since we get
enough "cygwin is slow" complaints, that wasn't a cost we were willing
to pay.

cgf
-

Btw, we're looking to roll out a new release of cygwin which fixes the
embarrassing typo in sockaddr_storage.  It is fixed in cygwin snapshots:

http://cygwin.com/snapshots/

cgf
-

Quick question for cygwin people (I asked this at an earlier point, but I 
don't think there was any reply): would cygwin prefer using "vfork()" over 
"fork()", or is there no advantage? With vfork(), I could imagine that you 
might avoid a lot of strange VM games.. 

I think almost all of the git fork usage is of the type where "vfork()" 
would work fine (git-daemon in non-inetd form is an exception, perhaps the 
only one).

So if using vfork() is preferable, we probably should do that. It tends to 
be a small performance improvement on Linux too, although on Linux it's 
really pretty much in the noise.

Alternatively, is there anything else we can do that makes things easier?

			Linus
-

Sorry, I missed the earlier question.  I have to get in the habit of
scanning this list more regularly for this type of thing.

Cygwin's vfork implementation currently defaults to fork so it doesn't
matter which is used.

We used to have a vfork which tried to cut down on some of the
substantial overhead that comes with cygwin's fork() but the vfork
implementation eventually grew so complicated that there was eventually
no performance gain and I decided to just yank it and revisit it at
a later point.

So, for now, there is no difference, but, eventually, there might be if
someone masters courage to revisit vfork-on-cygwin.

So, I guess that means that it would be a good idea to switch to vfork
if you were planning for the nebulous future when this made a difference

I'm really committed to making cygwin as much like linux as possible so
that you won't have to make things easier.  The last release added some
stuff which should make building linux easier, in fact.  Also, the
mmap() implementation should be a littler closer to linux.  It is, of
course, a work in progress, though.

The only thing that would speed up process creation in cygwin now is
the use of the windows spawn* family of function calls.  Those could be
used instead of fork/exec but I have a personal aversion to using them
since they are so non-UNIX.  If performance is an issue, however, that
could be something to investigate.

cgf
-

What about posix_spawn()? I don't know the windows spawn things, but I 
assume posix_spawn() is basically trying to be them.. Does it work with 
cygwin if we try to convert some of the more obvious users?

Some of the git users should be easy to convert to posix_spawn()..

		Linus
-

You know, I couldn't remember what the name of the spawn that was
introduced for posix.  I was going to mention it in my email and I
forgot.  Obviously it was because the name so obscure that no one could
possibly remember it.  :-)

We don't emulate posix_spawn currently but we could and should.  I'll
put it on the todo list.

cgf
-