[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: busybox under the Hurd



> busybox: ping.c fails due to undeclared MAXHOSTNAMELEN, it is defined in
> rpc/types.h, it is also defined in asm/param.h. ping.c gets its value
> via sys/param.h which calls linux/param.h which calls asm/param.h.
> I can get around this easily enough by calling rpc/types.h under both
> linux and hurd.

The better solution is to fix it to use dynamic allocation.
On the Hurd, there is no fixed limit on the host name length.

> ping.c also fails with a dereferencing pointer to incomplete type, the
> type in question is struct iphdr, under linux it is defined in
> netinet/ip.h however the version of netinet/ip.h under the Hurd doesnt
> have struct iphdr defined.

Hmm.  We define the BSD-compatible `struct ip' instead of the Linux
invention `struct iphdr' (they have the same layout, but different member
names).  This must have come up before.  Maybe Mark or Marcus remembers
something about this (you might try searching for iphdr in the mailing list
archives).

> which.c fails due to undeclared PATH_MAX, which is declared under
> linux/limits.h at value 4095, path max doesnt seem to be declared
> anywhere under hurd, i guess i can do an #ifndef PATH_MAX  #define
> PATH_MAX 4095

The better solution is to fix it to use dynamic allocation.
On the Hurd, there is no fixed limit on file name length.

> gunzip.c fails due to a redefinition of basename due to the following
> code in gunzip.c
> 
> #ifndef __linux__
> static char *basename(char *fname);
> #endif
> 
> I commented out that section and it worked, so i think i need to do
> something like
> #ifndef __linux__ || ifndef __hurd__
> static char *basename(char *fname);
> #endif

The better change is just rename the damn function.  The basename function
is in some standard, so the application should avoid that name.

> free.c, init.c, uname.c and uptime.c all depend on struct sysinfo which
> is defined in linux/kernel.h, it has the following structure.

There is no direct analog to that.  I don't know what call it expects to
return such a structure, anyway.  The information about memory can be
gotten with some Mach calls that you can see used in the Hurd's vmstat
(hurd/utils/vmstat.c).  The uptime is a little complex to retrieve; see
hurd/utils/w.c for the code that does it in w and uptime, which use the
Hurd's -lps (shared) library.  

> uname.c uses sysinfo to get cpu name (i think) 

If you look at the structure, there is nothing like that there.
See what it is really used for.



Reply to: