Re: [PATCH] Use the standard libc types in fatattr
On Sat, Jul 5, 2014 at 1:51 PM, Rich Felker wrote: > On Sat, Jul 05, 2014 at 12:20:51PM +0100, Laszlo Papp wrote: > > > To be pedantic, uint32_t was introduced in the Open Group Base > > > Specifications, Issue 5 (released in 1997, basis for UNIX98). > > > At that point it was defined in , which only defined > > > (u)int*_t. > > > > > > As far as when was available, it was first shipped in > glibc > > > 2.1 > > > (and prereleases thereof), meaning it was first packaged in Debian 2.1 > > > (slink) on sparc. Slink shipped with kernel 2.0.36. > > > But the names of sized types in the kernel _could_ have been switched > > > over when the standard was released, or rather during any of the > "unstable" > > > series after that; this is not a compiler change but a header change, > > > and the kernel has its own headers. Kernel 2.0 was released in 1996 > > > (before the standard), but 2.2, 2.4, and 2.6 were released in 1999, > > > 2001, and 2003. > > > > > > > Glibc is not the only thing, in fact it has not been used much in > embedded, > > and even today, it is mostly for "computing embedded". > > From a header standpoint, uClibc effectively is (an old version of) > glibc. From well after the standard types were added. So this is not > an argument against using them. > I was not even referring to uClibc, eventually ... > > > The real reason is mentioned in the kernel coding style manual: > > > some people don't like the "new" types. > > > > > > > Tes... for good: "do not fix what is not broken". > > "Do not fix what is not broken" does not apply here. The kernel > headers have ALWAYS been broken for use in userspace. The UAPI effort > has partly fixed this (and is evidence that they _are_ trying to fix > this, albeit poorly). > Just because you have a different personal style, it does not mean it is broken. It has served and made Linux popular for well over a decade and a half. Again, I like the bikeshed pink. > > Rich > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Sat, Jul 05, 2014 at 12:20:51PM +0100, Laszlo Papp wrote: > > To be pedantic, uint32_t was introduced in the Open Group Base > > Specifications, Issue 5 (released in 1997, basis for UNIX98). > > At that point it was defined in , which only defined > > (u)int*_t. > > > > As far as when was available, it was first shipped in glibc > > 2.1 > > (and prereleases thereof), meaning it was first packaged in Debian 2.1 > > (slink) on sparc. Slink shipped with kernel 2.0.36. > > But the names of sized types in the kernel _could_ have been switched > > over when the standard was released, or rather during any of the "unstable" > > series after that; this is not a compiler change but a header change, > > and the kernel has its own headers. Kernel 2.0 was released in 1996 > > (before the standard), but 2.2, 2.4, and 2.6 were released in 1999, > > 2001, and 2003. > > > > Glibc is not the only thing, in fact it has not been used much in embedded, > and even today, it is mostly for "computing embedded". >From a header standpoint, uClibc effectively is (an old version of) glibc. From well after the standard types were added. So this is not an argument against using them. > > The real reason is mentioned in the kernel coding style manual: > > some people don't like the "new" types. > > > > Tes... for good: "do not fix what is not broken". "Do not fix what is not broken" does not apply here. The kernel headers have ALWAYS been broken for use in userspace. The UAPI effort has partly fixed this (and is evidence that they _are_ trying to fix this, albeit poorly). Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Sat, Jul 5, 2014 at 12:38 AM, Isaac Dunham wrote:
> On Fri, Jul 04, 2014 at 03:06:04PM +0100, Laszlo Papp wrote:
> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko >
> > wrote:
> >
> > > On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
> > > >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> > > >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> > > >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10,
> uint32_t)
> > > >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11,
> uint32_t)
> > > >> > #endif
> > > >> >
> > > >> > /* Currently supports only the FAT flags, not the NTFS ones.
> > > >>
> > > >>
> > > >> Applied, thanks!
> > > >>
> > > >> (why kernel doesn't just use std types?...)
> > > >
> > > > What do you mean by "std types"?
> > >
> > > Like uint32_t
> > >
> >
> > As indicated before, it was only introduced in C99. The kernel project
> > predates that for one.
>
> To be pedantic, uint32_t was introduced in the Open Group Base
> Specifications, Issue 5 (released in 1997, basis for UNIX98).
> At that point it was defined in , which only defined
> (u)int*_t.
>
> As far as when was available, it was first shipped in glibc
> 2.1
> (and prereleases thereof), meaning it was first packaged in Debian 2.1
> (slink) on sparc. Slink shipped with kernel 2.0.36.
> But the names of sized types in the kernel _could_ have been switched
> over when the standard was released, or rather during any of the "unstable"
> series after that; this is not a compiler change but a header change,
> and the kernel has its own headers. Kernel 2.0 was released in 1996
> (before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
> 2001, and 2003.
>
Glibc is not the only thing, in fact it has not been used much in embedded,
and even today, it is mostly for "computing embedded".
>
> The real reason is mentioned in the kernel coding style manual:
> some people don't like the "new" types.
>
Tes... for good: "do not fix what is not broken".
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 04, 2014 at 03:06:04PM +0100, Laszlo Papp wrote:
> On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko
> wrote:
>
> > On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
> > >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> > >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> > >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> > >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> > >> > #endif
> > >> >
> > >> > /* Currently supports only the FAT flags, not the NTFS ones.
> > >>
> > >>
> > >> Applied, thanks!
> > >>
> > >> (why kernel doesn't just use std types?...)
> > >
> > > What do you mean by "std types"?
> >
> > Like uint32_t
> >
>
> As indicated before, it was only introduced in C99. The kernel project
> predates that for one.
To be pedantic, uint32_t was introduced in the Open Group Base
Specifications, Issue 5 (released in 1997, basis for UNIX98).
At that point it was defined in , which only defined
(u)int*_t.
As far as when was available, it was first shipped in glibc 2.1
(and prereleases thereof), meaning it was first packaged in Debian 2.1
(slink) on sparc. Slink shipped with kernel 2.0.36.
But the names of sized types in the kernel _could_ have been switched
over when the standard was released, or rather during any of the "unstable"
series after that; this is not a compiler change but a header change,
and the kernel has its own headers. Kernel 2.0 was released in 1996
(before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
2001, and 2003.
The real reason is mentioned in the kernel coding style manual:
some people don't like the "new" types.
Thanks,
Isaac Dunham
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 4:27 PM, Laszlo Papp wrote:
>
>
>
> On Fri, Jul 4, 2014 at 3:25 PM, Denys Vlasenko
> wrote:
>
>> On Fri, Jul 4, 2014 at 4:06 PM, Laszlo Papp wrote:
>> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko <
>> vda.li...@googlemail.com>
>> > wrote:
>> >>
>> >> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
>> >> >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
>> >> >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
>> >> >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10,
>> uint32_t)
>> >> >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11,
>> uint32_t)
>> >> >> > #endif
>> >> >> >
>> >> >> > /* Currently supports only the FAT flags, not the NTFS ones.
>> >> >>
>> >> >>
>> >> >> Applied, thanks!
>> >> >>
>> >> >> (why kernel doesn't just use std types?...)
>> >> >
>> >> > What do you mean by "std types"?
>> >>
>> >> Like uint32_t
>> >
>> >
>> > As indicated before, it was only introduced in C99. The kernel project
>> > predates that for one.
>>
>> I understand that.
>> It's 2014.
>> 15 years to convert to (now-)standard type should be doable.
>>
>
> How much have you developed the kernel, especially in the driver area?
>
> I can tell that the old golden rule applies here, especially for drivers:
> "Do not touch what is not broken.". It is hard to find people with the
> corresponding ICs to test such a minimal change unless the original author
> has free time for you to test it. Otherwise, you could potentially break a
> working driver.
>
> What is the benefit of the migration if you cannot test it and do not have
> time? Not much, really.
>
> Also, note that the kernel project is much bigger than busybox. 15 years
> is not much for such a big code base.
>
In addition, it is not really 15 years. It is not like you realize a new
standard in '99 and you have got a well working compiler for all the
platforms that Linux supports.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 3:25 PM, Denys Vlasenko
wrote:
> On Fri, Jul 4, 2014 at 4:06 PM, Laszlo Papp wrote:
> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko >
> > wrote:
> >>
> >> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
> >> >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> >> >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> >> >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> >> >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> >> >> > #endif
> >> >> >
> >> >> > /* Currently supports only the FAT flags, not the NTFS ones.
> >> >>
> >> >>
> >> >> Applied, thanks!
> >> >>
> >> >> (why kernel doesn't just use std types?...)
> >> >
> >> > What do you mean by "std types"?
> >>
> >> Like uint32_t
> >
> >
> > As indicated before, it was only introduced in C99. The kernel project
> > predates that for one.
>
> I understand that.
> It's 2014.
> 15 years to convert to (now-)standard type should be doable.
>
How much have you developed the kernel, especially in the driver area?
I can tell that the old golden rule applies here, especially for drivers:
"Do not touch what is not broken.". It is hard to find people with the
corresponding ICs to test such a minimal change unless the original author
has free time for you to test it. Otherwise, you could potentially break a
working driver.
What is the benefit of the migration if you cannot test it and do not have
time? Not much, really.
Also, note that the kernel project is much bigger than busybox. 15 years is
not much for such a big code base.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 04, 2014 at 04:25:11PM +0200, Denys Vlasenko wrote:
> On Fri, Jul 4, 2014 at 4:06 PM, Laszlo Papp wrote:
> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko
> > wrote:
> >>
> >> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
> >> >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> >> >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> >> >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> >> >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> >> >> > #endif
> >> >> >
> >> >> > /* Currently supports only the FAT flags, not the NTFS ones.
> >> >>
> >> >>
> >> >> Applied, thanks!
> >> >>
> >> >> (why kernel doesn't just use std types?...)
> >> >
> >> > What do you mean by "std types"?
> >>
> >> Like uint32_t
> >
> >
> > As indicated before, it was only introduced in C99. The kernel project
> > predates that for one.
>
> I understand that.
> It's 2014.
> 15 years to convert to (now-)standard type should be doable.
Yes. If the kernel would convert to using the stdint.h types and
provide its own stdint.h for use with -nostdinc when building the
kernel itself, the kernel headers would automatically be compatible
with userspace when used directly by applications like busybox.
On the other hand, if the kernel headers are intended to be used for
implementing some libc headers, they cannot depend on or pull in
stdint.h unless the corresponding libc header is allowed to do so; if
they did so, it would be namespace pollution. I suspect this is one of
the reasons they may be hesitant to use these types. Right now, all of
their wacky types are in the reserved namespace (double-underscore
prefix) and thus they don't have to worry about it.
Of course libc implementations should not be using kernel headers -- I
thought we learned that lesson 20 years ago with libc5 -- but uclibc
does so heavily and glibc even resurrected the practice at some point
for various things (especially socket stuff, and lots more on some
archs).
Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 4:06 PM, Laszlo Papp wrote:
> On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko
> wrote:
>>
>> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
>> >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
>> >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
>> >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
>> >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
>> >> > #endif
>> >> >
>> >> > /* Currently supports only the FAT flags, not the NTFS ones.
>> >>
>> >>
>> >> Applied, thanks!
>> >>
>> >> (why kernel doesn't just use std types?...)
>> >
>> > What do you mean by "std types"?
>>
>> Like uint32_t
>
>
> As indicated before, it was only introduced in C99. The kernel project
> predates that for one.
I understand that.
It's 2014.
15 years to convert to (now-)standard type should be doable.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko
wrote:
> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
> >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> >> > #endif
> >> >
> >> > /* Currently supports only the FAT flags, not the NTFS ones.
> >>
> >>
> >> Applied, thanks!
> >>
> >> (why kernel doesn't just use std types?...)
> >
> > What do you mean by "std types"?
>
> Like uint32_t
>
As indicated before, it was only introduced in C99. The kernel project
predates that for one.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp wrote:
>> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
>> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
>> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
>> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
>> > #endif
>> >
>> > /* Currently supports only the FAT flags, not the NTFS ones.
>>
>>
>> Applied, thanks!
>>
>> (why kernel doesn't just use std types?...)
>
> What do you mean by "std types"?
Like uint32_t
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 2:17 PM, Denys Vlasenko
wrote:
> On Fri, Jul 4, 2014 at 3:55 PM, Isaac Dunham wrote:
> > (rather than gratuitously copying every kernel-speific int type.)
> > ---
> > util-linux/fatattr.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/util-linux/fatattr.c b/util-linux/fatattr.c
> > index 0f8d632..5d93387 100644
> > --- a/util-linux/fatattr.c
> > +++ b/util-linux/fatattr.c
> > @@ -34,8 +34,8 @@
> > #include "libbb.h"
> > /* linux/msdos_fs.h says: */
> > #ifndef FAT_IOCTL_GET_ATTRIBUTES
> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> > #endif
> >
> > /* Currently supports only the FAT flags, not the NTFS ones.
>
>
> Applied, thanks!
>
> (why kernel doesn't just use std types?...)
>
What do you mean by "std types"? Those are definitely not standard for the
kernel. The kernel is built with older C standards than C99 at times.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Fri, Jul 4, 2014 at 3:55 PM, Isaac Dunham wrote:
> (rather than gratuitously copying every kernel-speific int type.)
> ---
> util-linux/fatattr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/util-linux/fatattr.c b/util-linux/fatattr.c
> index 0f8d632..5d93387 100644
> --- a/util-linux/fatattr.c
> +++ b/util-linux/fatattr.c
> @@ -34,8 +34,8 @@
> #include "libbb.h"
> /* linux/msdos_fs.h says: */
> #ifndef FAT_IOCTL_GET_ATTRIBUTES
> -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> #endif
>
> /* Currently supports only the FAT flags, not the NTFS ones.
Applied, thanks!
(why kernel doesn't just use std types?...)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Sat, Jul 5, 2014 at 8:31 AM, Isaac Dunham wrote: > On Thu, Jul 03, 2014 at 06:21:03AM +0100, Laszlo Papp wrote: > > Why do you submit another change? I already submitted one, and I am happy > > to update it if the maintainer requests any change? > > I'd misread your response "the important thing is to fix the build break" > That is the most important, isn't it? :-) That patch is still not being commented on by the maintainer though. ;-) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
On Thu, Jul 03, 2014 at 06:21:03AM +0100, Laszlo Papp wrote:
> Why do you submit another change? I already submitted one, and I am happy
> to update it if the maintainer requests any change?
I'd misread your response "the important thing is to fix the build break"
to John Spencer's comment as "if you want it done that way, send a patch
quick".
> This feels a bit unwelcoming. ;)
For which I apologize (as well as for the misunderstanding).
> On Fri, Jul 4, 2014 at 2:55 PM, Isaac Dunham wrote:
>
> > (rather than gratuitously copying every kernel-speific int type.)
> > ---
> > util-linux/fatattr.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/util-linux/fatattr.c b/util-linux/fatattr.c
> > index 0f8d632..5d93387 100644
> > --- a/util-linux/fatattr.c
> > +++ b/util-linux/fatattr.c
> > @@ -34,8 +34,8 @@
> > #include "libbb.h"
> > /* linux/msdos_fs.h says: */
> > #ifndef FAT_IOCTL_GET_ATTRIBUTES
> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> > #endif
> >
> > /* Currently supports only the FAT flags, not the NTFS ones.
> > --
> > 2.0.1
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Use the standard libc types in fatattr
Why do you submit another change? I already submitted one, and I am happy
to update it if the maintainer requests any change? This feels a bit
unwelcoming. ;)
On Fri, Jul 4, 2014 at 2:55 PM, Isaac Dunham wrote:
> (rather than gratuitously copying every kernel-speific int type.)
> ---
> util-linux/fatattr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/util-linux/fatattr.c b/util-linux/fatattr.c
> index 0f8d632..5d93387 100644
> --- a/util-linux/fatattr.c
> +++ b/util-linux/fatattr.c
> @@ -34,8 +34,8 @@
> #include "libbb.h"
> /* linux/msdos_fs.h says: */
> #ifndef FAT_IOCTL_GET_ATTRIBUTES
> -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
> +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
> #endif
>
> /* Currently supports only the FAT flags, not the NTFS ones.
> --
> 2.0.1
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] Use the standard libc types in fatattr
(rather than gratuitously copying every kernel-speific int type.)
---
util-linux/fatattr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util-linux/fatattr.c b/util-linux/fatattr.c
index 0f8d632..5d93387 100644
--- a/util-linux/fatattr.c
+++ b/util-linux/fatattr.c
@@ -34,8 +34,8 @@
#include "libbb.h"
/* linux/msdos_fs.h says: */
#ifndef FAT_IOCTL_GET_ATTRIBUTES
-# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
-# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
+# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, uint32_t)
+# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, uint32_t)
#endif
/* Currently supports only the FAT flags, not the NTFS ones.
--
2.0.1
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
