Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, It's not an easy task to get "noticed". Well, no i lie - that's easy, start submitting patches. Then you need to find someone who you can nag to get it done. I've offered to a few people to include stuff - just keep nagging me. Linux projects have the same problem, don't doubt it - but they have a larger group of active people, generally looking after a very specific corner of the world. If you want to join the fray and get a commit bit, just be persistent and be willing to look after one specific corner of the tree. Then you'll be responsible for dealing with others nagging you. :) Getting to that point can take a bit of effort though. In terms of wifi, I jumped in with both feet and asked a whole bunch of questions (and nagged a whole lot of people) until I wrapped my head around things. This may or may not be the way you work. :-) The trouble is it's just (mostly) me. It's a little overwhelming, especially since I don't subscribe to the "copy everyone elses' work and hope it works fine" method of working.. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
On Fri, Jan 20, 2012 at 07:09:43PM -0500, Eitan Adler wrote:
> 2012/1/20 Kostik Belousov :
> > On Fri, Jan 20, 2012 at 06:25:42PM -0500, Eitan Adler wrote:
> >> I figure this isn't wanted?
> > You silently ignored part of the notes that were provided,
>
> I fixed the style violations you pointed out and removed
> _SYS_SYSPROTO_H_ and friends. Which else was there? If I missed
> something I'm sorry.
Manual definition of the struct dup3_args is not needed at all. I
very much doubt that patch can compile since there is now
duplicate definition of the structure.
There is still stray return (0);.
Another reason for the patch to not compile is compat32
syscalls.master changes.
The suggestion of 'it is better to test the presence of O_CLOEXEC
with & instead of comparing with ==, to allow for ease
introduction of future dup3 flags, if any.' is silently ignored.
Probably new: style requires putting opening '{' for the function
body at new line. There shall be no space between '*' and arg name.
New: symbols in the version map shall be ordered alphabetically.
>
> > and keep
> > complete silence on the primary question about non-standard
>
> I thought I answered that already but I'll try again: I believe the
> functionality is useful to developers even if it is non-standard. In
> addition if it is standardized at some point in the future it is
> unlikely to have different semantics than the ones implemented.
It very well may have different details that would force us to
draw two versions forever.
>
> > and fractional nature of the patch.
>
> How so? I am not including the generated parts in the patch. Should I?
The implementation is partial because dup3() is only part of the
Linux and glibc efforts to allow app authors to handle the race
between obtaining the file descriptor and setting cloexec flag. I
already pointed you to SOCK_CLOEXEC for example. This is ignored
as well.
dup3() alone is almost useless.
>
> > I see no reason to retype my previous response.
>
> --
> Eitan Adler
pgpL6B1rXwfLx.pgp
Description: PGP signature
