[PATCH 1/3] bits/socket.h: Define SO_RCVBUFFORCE for mips

[PATCH 1/3] bits/socket.h: Define SO_RCVBUFFORCE for mips

[Khem Raj]

packages like udev are using it

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Upstream-Status: Pending
---
 arch/mips/bits/socket.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/bits/socket.h b/arch/mips/bits/socket.h
index ba79045..2264679 100644
--- a/arch/mips/bits/socket.h
+++ b/arch/mips/bits/socket.h
@@ -31,6 +31,7 @@ struct cmsghdr
 #define SO_RCVBUF       0x1002
 #define SO_KEEPALIVE    8
 #define SO_OOBINLINE    256
+#define SO_RCVBUFFORCE  33
 
 #define SO_NO_CHECK     11
 #define SO_PRIORITY     12
-- 
1.7.10.4

[PATCH 2/3] Add soname to dynamic section

[Khem Raj]

Its used by post processing tools especially
during packaging to construct package names etc.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Upstream-Status: Pending
---
 Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 0ab0bfd..cffa519 100644
--- a/Makefile
+++ b/Makefile
@@ -126,6 +126,7 @@ $(foreach s,$(wildcard src/*/$(ARCH)*/*.s),$(eval $(call mkasmdep,$(s))))
 lib/libc.so: $(LOBJS)
 	$(CC) $(CFLAGS_ALL_SHARED) $(LDFLAGS) -nostdlib -shared \
 	-Wl,-e,_start -Wl,-Bsymbolic-functions \
+	-Wl,-soname,libc.so \
 	-o $@ $(LOBJS) $(LIBCC)
 
 lib/libc.a: $(OBJS)
-- 
1.7.10.4

Re: [PATCH 2/3] Add soname to dynamic section

[Rich Felker]

On Sun, Apr 27, 2014 at 06:43:53PM -0700, Khem Raj wrote:
> Its used by post processing tools especially
> during packaging to construct package names etc.

This is intentionally omitted. If it exists on a system where glibc is
also present, running ldconfig will create a symlink named libc.so in
/lib pointing to ld-musl-$ARCH.so.1.

What exactly are you trying to achieve by adding it?

Rich

Re: [PATCH 2/3] Add soname to dynamic section

[Khem Raj]

On Sun, Apr 27, 2014 at 7:00 PM, Rich Felker <dalias@libc.org> wrote:
> This is intentionally omitted. If it exists on a system where glibc is
> also present, running ldconfig will create a symlink named libc.so in
> /lib pointing to ld-musl-$ARCH.so.1.
>
> What exactly are you trying to achieve by adding it?

I am bootstrapping system using OpenEmbedded/musl and we use the
content of SONAME
to rename the library package as well as shlibs code then uses it to
for dependencies as well. I kept it libc.so for simplicity but it
could be a distinct name. Coexisting with glibc is not  my usecase.
here. but if you have libc.so in /usr/lib then you are in conflict
with glibc anyway, how do you handle that ?

Re: [PATCH 2/3] Add soname to dynamic section

[Isaac Dunham]

On Sun, Apr 27, 2014 at 10:02:45PM -0700, Khem Raj wrote:
> On Sun, Apr 27, 2014 at 7:00 PM, Rich Felker <dalias@libc.org> wrote:
> > This is intentionally omitted. If it exists on a system where glibc is
> > also present, running ldconfig will create a symlink named libc.so in
> > /lib pointing to ld-musl-$ARCH.so.1.
> >
> > What exactly are you trying to achieve by adding it?
> 
> I am bootstrapping system using OpenEmbedded/musl and we use the
> content of SONAME
> to rename the library package as well as shlibs code then uses it to
> for dependencies as well. I kept it libc.so for simplicity but it
> could be a distinct name. Coexisting with glibc is not  my usecase.
> here. but if you have libc.so in /usr/lib then you are in conflict
> with glibc anyway, how do you handle that ?
Default configuration is to set libdir to /usr/local/musl/lib, and
syslibdir to /lib.
ld-musl-$ARCH.so.1 goes in syslibdir; the libc.so symlink is solely used
for dynamic linking and goes in libdir.
Putting libc.so in /usr/lib requires passing --prefix=/usr, as is 
specifically recommended against in INSTALL:
  DO NOT set the prefix to "/usr", "/usr/local", or "/" unless you're
  upgrading libc on an existing musl-based system. Doing so will break
  your system when you run "make install" and it may be difficult to
  recover.

The SONAME used to be in the makefile, but was removed due to people
encountering problems when they ran ldconfig.

For the record, here's the approach I used to fix a Debian system that I
hosed at least twice due to the SONAME causing trouble with ldconfig:
-boot to a busybox ash or other static shell (root=... rw init=/bin/...)
-manually correct the links if glibc is still installed;
otherwise use "busybox dpkg -i /var/cache/apt/archives/..." and check
that libc.so exists.
-sync twice, then reboot.

There are no problems with coxistence caused by the existing approach.

Hope this clarifies things,
Isaac Dunham

Re: [PATCH 2/3] Add soname to dynamic section

[Khem Raj]

On Sun, Apr 27, 2014 at 10:54 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:
>
> The SONAME used to be in the makefile, but was removed due to people
> encountering problems when they ran ldconfig.

well, it seems coexisting is another usecase. My systems are
bootstrapped with musl so I do not worry about ldconfig and glibc
being around.
so may be making soname configurable
(--enable-soname/--disable-soname) is middle ground

Re: [PATCH 2/3] Add soname to dynamic section

[Isaac Dunham]

On Sun, Apr 27, 2014 at 11:00:16PM -0700, Khem Raj wrote:
> On Sun, Apr 27, 2014 at 10:54 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:
> >
> > The SONAME used to be in the makefile, but was removed due to people
> > encountering problems when they ran ldconfig.
> 
> well, it seems coexisting is another usecase. My systems are
> bootstrapped with musl so I do not worry about ldconfig and glibc
> being around.
> so may be making soname configurable
> (--enable-soname/--disable-soname) is middle ground

It should be possible to add -Wl,-soname=libc.so to LDFLAGS.
For example,
./configure --prefix=/usr --libdir=/lib LDFLAGS="-Wl,-soname=libc.so"

HTH,
Isaac Dunham

Re: [PATCH 2/3] Add soname to dynamic section

[Timo Teras]

On Sun, 27 Apr 2014 23:22:40 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Sun, Apr 27, 2014 at 11:00:16PM -0700, Khem Raj wrote:
> > On Sun, Apr 27, 2014 at 10:54 PM, Isaac Dunham <ibid.ag@gmail.com>
> > wrote:
> > >
> > > The SONAME used to be in the makefile, but was removed due to
> > > people encountering problems when they ran ldconfig.
> > 
> > well, it seems coexisting is another usecase. My systems are
> > bootstrapped with musl so I do not worry about ldconfig and glibc
> > being around.
> > so may be making soname configurable
> > (--enable-soname/--disable-soname) is middle ground
> 
> It should be possible to add -Wl,-soname=libc.so to LDFLAGS.
> For example,
> ./configure --prefix=/usr --libdir=/lib LDFLAGS="-Wl,-soname=libc.so"

Yes, that works. This is what we do in Alpine Linux:
http://git.alpinelinux.org/cgit/aports/tree/main/musl/APKBUILD#n75

- Timo

Re: [PATCH 2/3] Add soname to dynamic section

[Khem Raj]

> It should be possible to add -Wl,-soname=libc.so to LDFLAGS.
> For example,
> ./configure --prefix=/usr --libdir=/lib LDFLAGS="-Wl,-soname=libc.so"

Yes. already dropped it in.

Re: [PATCH 2/3] Add soname to dynamic section

[Rich Felker]

On Mon, Apr 28, 2014 at 12:20:39AM -0700, Khem Raj wrote:
> > It should be possible to add -Wl,-soname=libc.so to LDFLAGS.
> > For example,
> > ./configure --prefix=/usr --libdir=/lib LDFLAGS="-Wl,-soname=libc.so"
> 
> Yes. already dropped it in.

This is fairly harmless, but note that it could be harmful to add
-Wl,-soname=xxx with different values of xxx. In particular, if the
soname is not of the form "libc.*", the dynamic linker will attempt to
load it (not knowing it's libc) and very bad things will happen when
libc is loaded twice in the same process.

Rich

[PATCH 3/3] stddef: Define max_align_t

[Khem Raj]

c++11 defines is and libstdc++ from gcc 4.9 now needs it

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Upstream-Status: Pending
---
 include/stddef.h |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/stddef.h b/include/stddef.h
index 0a32919..788227a 100644
--- a/include/stddef.h
+++ b/include/stddef.h
@@ -19,4 +19,9 @@
 #define offsetof(type, member) ((size_t)( (char *)&(((type *)0)->member) - (char *)0 ))
 #endif
 
+typedef struct {
+      long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
+        long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
+} max_align_t;
+
 #endif
-- 
1.7.10.4

Re: [PATCH 3/3] stddef: Define max_align_t

[Rich Felker]

On Sun, Apr 27, 2014 at 06:43:54PM -0700, Khem Raj wrote:
> c++11 defines is and libstdc++ from gcc 4.9 now needs it

Is it also in C11 or just C++11? If it's not in C11 it needs to be
namespace protected.

> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> 
> Upstream-Status: Pending
> ---
>  include/stddef.h |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/stddef.h b/include/stddef.h
> index 0a32919..788227a 100644
> --- a/include/stddef.h
> +++ b/include/stddef.h
> @@ -19,4 +19,9 @@
>  #define offsetof(type, member) ((size_t)( (char *)&(((type *)0)->member) - (char *)0 ))
>  #endif
>  
> +typedef struct {
> +      long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
> +        long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
> +} max_align_t;
> +

As far as I can tell, there's no reason to use the attribute here.
What's it there for? Also a union would probably be nicer than a
struct, but perhaps it doesn't matter.

Rich

Re: [PATCH 3/3] stddef: Define max_align_t

[Khem Raj]

On Sun, Apr 27, 2014 at 7:03 PM, Rich Felker <dalias@libc.org> wrote:
> On Sun, Apr 27, 2014 at 06:43:54PM -0700, Khem Raj wrote:
>> c++11 defines is and libstdc++ from gcc 4.9 now needs it
>
> Is it also in C11 or just C++11? If it's not in C11 it needs to be
> namespace protected.

yes its for both so may  something like

#if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L

>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>
>> Upstream-Status: Pending
>> ---
>>  include/stddef.h |    5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/include/stddef.h b/include/stddef.h
>> index 0a32919..788227a 100644
>> --- a/include/stddef.h
>> +++ b/include/stddef.h
>> @@ -19,4 +19,9 @@
>>  #define offsetof(type, member) ((size_t)( (char *)&(((type *)0)->member) - (char *)0 ))
>>  #endif
>>
>> +typedef struct {
>> +      long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
>> +        long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
>> +} max_align_t;
>> +
>
> As far as I can tell, there's no reason to use the attribute here.
> What's it there for? Also a union would probably be nicer than a
> struct, but perhaps it doesn't matter.

union does not return correct alignment where as struct did. I just
tried to match
what clang also has

http://reviews.llvm.org/rL201729


>
> Rich

Re: [PATCH 3/3] stddef: Define max_align_t

[Szabolcs Nagy]

* Khem Raj <raj.khem@gmail.com> [2014-04-27 22:51:34 -0700]:
> On Sun, Apr 27, 2014 at 7:03 PM, Rich Felker <dalias@libc.org> wrote:
> >> +typedef struct {
> >> +      long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
> >> +        long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
> >> +} max_align_t;
> >> +
> >
> > As far as I can tell, there's no reason to use the attribute here.
> > What's it there for? Also a union would probably be nicer than a
> > struct, but perhaps it doesn't matter.
> 
> union does not return correct alignment where as struct did. I just
> tried to match
> what clang also has
> 
> http://reviews.llvm.org/rL201729
> 

nice..

i think i386 abi is non-conforming to the c11 alignment requirements now:
long long has 8 byte alignment, but in a struct/union it has only 4
(this is why the attrs are needed above)

	long long x; // _Alignof(x) == 8
	struct {long long x;} y; // _Alignof(y.x) == 4

i think the standard requires that all (addressable) long long objects
should have the same alignment (or stricter) than _Alignof(x)

max_align_t is defined to be the "greatest alignment supported in all
contexts", i don't know why it is not just

	typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__)));

which gives 16 byte alignment on i386 gcc, i thought it was supported
in all contexts

if gcc and clang went with the same definition we should follow, but
this makes the type less meaningful

Re: [PATCH 3/3] stddef: Define max_align_t

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

Am Montag, den 28.04.2014, 12:11 +0200 schrieb Szabolcs Nagy:
> i think i386 abi is non-conforming to the c11 alignment requirements now:
> long long has 8 byte alignment, but in a struct/union it has only 4
> (this is why the attrs are needed above)
> 
> 	long long x; // _Alignof(x) == 8
> 	struct {long long x;} y; // _Alignof(y.x) == 4

I don't think that it is non-conforming

_Alignof of a type only tells you on what alignments the programmer
may place objects of the corresponding type (if he deals with this
manually) and gives no guarantee what the implementation itself choses
under all circumstances

this holds especially if a type has "extended alignment", I think

> i think the standard requires that all (addressable) long long objects
> should have the same alignment (or stricter) than _Alignof(x)
> 
> max_align_t is defined to be the "greatest alignment supported in all
> contexts", i don't know why it is not just

This only concerns "fundamental alignments". Also, this sentence has
an implicit "minimum" operator that comes from the "in all contexts"

if the alignment restriction is 8 in some context and 4 in others, the
result is 4 and not 8.

Perhaps all of this can be made consistent on i386 by having
_Alignof(max_align_t) to be 4 and declare 8 byte and 16 byte aligned
types as having "extended alignment"

I am not sure that I remember correctly, but it seems to me that i386
allows for 4 byte alignment of all types, only that this results in
suboptimal code

> 	typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__)));
> 
> which gives 16 byte alignment on i386 gcc, i thought it was supported
> in all contexts

I think this just not necessary and even counter productive.

> if gcc and clang went with the same definition we should follow, but
> this makes the type less meaningful

By looking at the page that you linked to, my impression is that they
got it wrong. I think basically

typedef union max_align_t max_align_t;

union max_align_t {
  long double a;
  uintmax_t b;
  void* c;
  max_align_t* d;
};

should do the trick. All other alignments should be considered as
extended alignments.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 3/3] stddef: Define max_align_t

[Szabolcs Nagy]

* Jens Gustedt <jens.gustedt@inria.fr> [2014-04-28 14:22:44 +0200]:
> Am Montag, den 28.04.2014, 12:11 +0200 schrieb Szabolcs Nagy:
> > i think i386 abi is non-conforming to the c11 alignment requirements now:
> > long long has 8 byte alignment, but in a struct/union it has only 4
> > (this is why the attrs are needed above)
> > 
> > 	long long x; // _Alignof(x) == 8
> > 	struct {long long x;} y; // _Alignof(y.x) == 4
> 
> I don't think that it is non-conforming
> 
> _Alignof of a type only tells you on what alignments the programmer
> may place objects of the corresponding type (if he deals with this
> manually) and gives no guarantee what the implementation itself choses
> under all circumstances
> 
> this holds especially if a type has "extended alignment", I think

the standard says

"An object type imposes an alignment requirement on every object of that
type: stricter alignment can be requested using the _Alignas keyword."

"The _Alignof operator yields the alignment requirement of its operand type."

to me this means that all long long objects should have the same
alignment requirement and _Alignof should return this consistently
(unless _Alignas imposes further stricter alignment requirements,
but it never gets weaker)

in my example x and y.x are long long objects but have different
alignment requirements

there is no exception here for types with extended alignments or
"alignment support contexts"

> > i think the standard requires that all (addressable) long long objects
> > should have the same alignment (or stricter) than _Alignof(x)

(it seems that _Alignof is specified for objects with register storage
class too, so even non-addressable long longs should have the same
alignment requirement whatever that means)

> > max_align_t is defined to be the "greatest alignment supported in all
> > contexts", i don't know why it is not just
> 
> This only concerns "fundamental alignments". Also, this sentence has
> an implicit "minimum" operator that comes from the "in all contexts"
> 
> if the alignment restriction is 8 in some context and 4 in others, the
> result is 4 and not 8.
>
> Perhaps all of this can be made consistent on i386 by having
> _Alignof(max_align_t) to be 4 and declare 8 byte and 16 byte aligned
> types as having "extended alignment"
> 

no, long long (or any scalar type) cannot be an "over-aligned" type

"A type having an extended alignment requirement is an over-aligned type."
"Every over-aligned type is, or contains, a structure or union type with
a member to which an extended alignment has been applied."

> I am not sure that I remember correctly, but it seems to me that i386
> allows for 4 byte alignment of all types, only that this results in
> suboptimal code

if long long has an alignment requirement of 4 byte then _Alignof should say so

> > 	typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__)));
> > 
> > which gives 16 byte alignment on i386 gcc, i thought it was supported
> > in all contexts
> 
> I think this just not necessary and even counter productive.

depends on what is the semantic meaning of max_align_t

currently it means "guaranteed to be supported in all contexts"

> > if gcc and clang went with the same definition we should follow, but
> > this makes the type less meaningful
> 
> By looking at the page that you linked to, my impression is that they
> got it wrong. I think basically
> 
> typedef union max_align_t max_align_t;
> 
> union max_align_t {
>   long double a;
>   uintmax_t b;
>   void* c;
>   max_align_t* d;
> };
> 
> should do the trick. All other alignments should be considered as
> extended alignments.

the implementation may support greater alignments

Re: [PATCH 3/3] stddef: Define max_align_t

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Am Montag, den 28.04.2014, 15:26 +0200 schrieb Szabolcs Nagy:
> no, long long (or any scalar type) cannot be an "over-aligned" type
> 
> "A type having an extended alignment requirement is an over-aligned type."
> "Every over-aligned type is, or contains, a structure or union type with
> a member to which an extended alignment has been applied."

The later is a footnote and so not normative, merely an explanation.

As a restrictive, normative text it makes not much sense to me anyhow.

> > I am not sure that I remember correctly, but it seems to me that i386
> > allows for 4 byte alignment of all types, only that this results in
> > suboptimal code
> 
> if long long has an alignment requirement of 4 byte then _Alignof should say so

I agree that this would certainly easier to cope with

(the compiler could still place them silently on 8 byte boundaries,
where it suits)

> > > 	typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__)));
> > > 
> > > which gives 16 byte alignment on i386 gcc, i thought it was supported
> > > in all contexts
> > 
> > I think this just not necessary and even counter productive.
> 
> depends on what is the semantic meaning of max_align_t
> 
> currently it means "guaranteed to be supported in all contexts"

I think this isn't explicitly mentioned somewhere, but my expectation
is that the alignment of this type is the one that is guaranteed by
malloc and friends. That should be the only semantic to expect from
it.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 3/3] stddef: Define max_align_t

[Rich Felker]

On Mon, Apr 28, 2014 at 03:26:45PM +0200, Szabolcs Nagy wrote:
> * Jens Gustedt <jens.gustedt@inria.fr> [2014-04-28 14:22:44 +0200]:
> > Am Montag, den 28.04.2014, 12:11 +0200 schrieb Szabolcs Nagy:
> > > i think i386 abi is non-conforming to the c11 alignment requirements now:
> > > long long has 8 byte alignment, but in a struct/union it has only 4
> > > (this is why the attrs are needed above)
> > > 
> > > 	long long x; // _Alignof(x) == 8
> > > 	struct {long long x;} y; // _Alignof(y.x) == 4
> > 
> > I don't think that it is non-conforming
> > 
> > _Alignof of a type only tells you on what alignments the programmer
> > may place objects of the corresponding type (if he deals with this
> > manually) and gives no guarantee what the implementation itself choses
> > under all circumstances
> > 
> > this holds especially if a type has "extended alignment", I think
> 
> the standard says
> 
> "An object type imposes an alignment requirement on every object of that
> type: stricter alignment can be requested using the _Alignas keyword."
> 
> "The _Alignof operator yields the alignment requirement of its operand type."
> 
> to me this means that all long long objects should have the same
> alignment requirement and _Alignof should return this consistently
> (unless _Alignas imposes further stricter alignment requirements,
> but it never gets weaker)

This is correct. On i386, _Alignof must both always be 4 for both long
long and long double, regardless of where the operand (if it's an
object rather than a type) exists. If gcc is behaving differently,
this is a very bad bug in GCC that needs to be fixed on their side; I
won't try to work around it.

Rich

Re: [PATCH 1/3] bits/socket.h: Define SO_RCVBUFFORCE for mips

[Rich Felker]

On Sun, Apr 27, 2014 at 06:43:52PM -0700, Khem Raj wrote:
> packages like udev are using it
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> 
> Upstream-Status: Pending
> ---
>  arch/mips/bits/socket.h |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/mips/bits/socket.h b/arch/mips/bits/socket.h
> index ba79045..2264679 100644
> --- a/arch/mips/bits/socket.h
> +++ b/arch/mips/bits/socket.h
> @@ -31,6 +31,7 @@ struct cmsghdr
>  #define SO_RCVBUF       0x1002
>  #define SO_KEEPALIVE    8
>  #define SO_OOBINLINE    256
> +#define SO_RCVBUFFORCE  33
>  
>  #define SO_NO_CHECK     11
>  #define SO_PRIORITY     12
> -- 
> 1.7.10.4

I think this is correct, but are there additional new SO_*'s that
should be added to mips, or is this value the same as on other archs
and perhaps not something that should be arch-specific to begin with?

Rich

Re: [PATCH 1/3] bits/socket.h: Define SO_RCVBUFFORCE for mips

[Khem Raj]

On Mon, Apr 28, 2014 at 7:29 AM, Rich Felker <dalias@libc.org> wrote:
> On Sun, Apr 27, 2014 at 06:43:52PM -0700, Khem Raj wrote:
>> packages like udev are using it
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>
>> Upstream-Status: Pending
>> ---
>>  arch/mips/bits/socket.h |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/mips/bits/socket.h b/arch/mips/bits/socket.h
>> index ba79045..2264679 100644
>> --- a/arch/mips/bits/socket.h
>> +++ b/arch/mips/bits/socket.h
>> @@ -31,6 +31,7 @@ struct cmsghdr
>>  #define SO_RCVBUF       0x1002
>>  #define SO_KEEPALIVE    8
>>  #define SO_OOBINLINE    256
>> +#define SO_RCVBUFFORCE  33
>>
>>  #define SO_NO_CHECK     11
>>  #define SO_PRIORITY     12
>> --
>> 1.7.10.4
>
> I think this is correct, but are there additional new SO_*'s that
> should be added to mips, or is this value the same as on other archs
> and perhaps not something that should be arch-specific to begin with?

I think redefining them in mips specific sockets.h is not needed. it
could use the values
from sys/socket.h

>
> Rich

Re: [PATCH 1/3] bits/socket.h: Define SO_RCVBUFFORCE for mips

[Rich Felker]

On Mon, Apr 28, 2014 at 07:54:26AM -0700, Khem Raj wrote:
> On Mon, Apr 28, 2014 at 7:29 AM, Rich Felker <dalias@libc.org> wrote:
> > On Sun, Apr 27, 2014 at 06:43:52PM -0700, Khem Raj wrote:
> >> packages like udev are using it
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >>
> >> Upstream-Status: Pending
> >> ---
> >>  arch/mips/bits/socket.h |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/mips/bits/socket.h b/arch/mips/bits/socket.h
> >> index ba79045..2264679 100644
> >> --- a/arch/mips/bits/socket.h
> >> +++ b/arch/mips/bits/socket.h
> >> @@ -31,6 +31,7 @@ struct cmsghdr
> >>  #define SO_RCVBUF       0x1002
> >>  #define SO_KEEPALIVE    8
> >>  #define SO_OOBINLINE    256
> >> +#define SO_RCVBUFFORCE  33
> >>
> >>  #define SO_NO_CHECK     11
> >>  #define SO_PRIORITY     12
> >> --
> >> 1.7.10.4
> >
> > I think this is correct, but are there additional new SO_*'s that
> > should be added to mips, or is this value the same as on other archs
> > and perhaps not something that should be arch-specific to begin with?
> 
> I think redefining them in mips specific sockets.h is not needed. it
> could use the values
> from sys/socket.h

On further review, this value doesn't seem mips-specific, but the
also-missing SO_SNDBUFFORCE is mips-specific in value. :( So I'm just
adding both to the mips version. Cleanup can come later.

Rich