This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: makedev
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: Shaun Jackman <sjackman at gmail dot com>
- Cc: Newlib List <newlib at sources dot redhat dot com>
- Date: Wed, 06 Apr 2005 06:49:27 +0200
- Subject: Re: makedev
- References: <7f45d939050405104254139ec6@mail.gmail.com>
On Tue, 2005-04-05 at 10:42 -0700, Shaun Jackman wrote:
> I'm compiling busybox with newlib. busybox uses the makedev macro
> which is defined in glibc's /usr/include/sys/sysmacros.h. glibc's
> sys/types.h includes sys/sysmacros.h if __USE_BSD is defined. So,
> busybox includes sys/types.h (which includes features.h which defines
> __USE_BSD) and expects makedev to be defined.
A bogus assumption.
The symbols to be provided through sys/types.h are well defined by
standards. makedev is not amongst these.
> So, should newlib be modfied to define makedev
I am not sure.
Though dev_t is covered by the standards and provided by newlib's
sys/types, it is an "opaque type".
Implementing makedev would require more knowledge about an OS's
internals, i.e. it violates this "opaqueness".
> (or alternatively include sys/sysmacros.h),
Neither. Generally speaking, sys/sysmacros.h is an implementation
detail. This file might be present or not on a particular OS and it
might provide makedev or not.
> or should busybox be modified to include sys/sysmacros.h itself?
Neither, again.
If busybox requires and relies upon "makedev" it needs to implement a
way to detect whatever resources it takes to get "makedev".
If it wants to be portable, it probably can't avoid to switch between
several alternatives of approaches to get "makedev", be it by using
preprocessor defines (#ifdef __linux__ ...) or by autoconf magic.
Ralf