Re: gpart FTBFS
Hi Harish,
2012/2/9 Jérémie Koenig j...@jk.fr.eu.org:
I'll try to have a look at your work this week-end, if nobody get to it by
then.
The issue seems to be with the disk geometry detection code in
src/disku.c, which returns an uninitialized structure on Hurd. I
attach a correction (use the size returned by stat(), as for disk
image files)
There also seems to be a problem with the way the geometry of disk
image files is detected, though. As far as I can tell, the code
computes the LBA address of the last sector, not actually the disk
geometry.
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
Index: gpart-0.1h/src/disku.c
===
--- gpart-0.1h.orig/src/disku.c 2012-02-12 13:42:17.0 +
+++ gpart-0.1h/src/disku.c 2012-02-13 00:57:20.0 +
@@ -25,14 +25,15 @@
#include errno.h
#include sys/mount.h
#include linux/hdreg.h
-#endif
-
-#if defined(__FreeBSD__)
+#elif defined(__FreeBSD__)
#include errno.h
#include sys/disklabel.h
+#elif defined(__GNU__)
+#include errno.h
#endif
#include unistd.h
+#include errno.h
/*
* get disk geometry. The medium is opened for reading,
@@ -46,8 +47,7 @@
#if defined(__linux__)
struct hd_geometry hg;
-#endif
-#if defined(__FreeBSD__)
+#elif defined(__FreeBSD__)
struct disklabel dl;
#endif
@@ -57,7 +57,10 @@
ret = stat(d-d_dev, st);
if (ret == 0)
{
+/* On Hurd, stat() returns the correct size even for block devices */
+#ifndef __GNU__
if (S_ISREG(st.st_mode))
+#endif
{
nsects = st.st_size / 512;
if (nsects == 0)
@@ -88,14 +91,23 @@
g.d_h = hg.heads;
g.d_s = hg.sectors;
-#endif
+#elif defined(__FreeBSD__)
-#if defined(__FreeBSD__)
if (ioctl(d-d_fd,DIOCGDINFO,dl) == -1)
pr(FATAL,EM_IOCTLFAILED,DIOCGDINFO,strerror(errno));
g.d_c = dl.d_ncylinders;
g.d_h = dl.d_ntracks;
g.d_s = dl.d_nsectors;
+
+#elif defined(__GNU__)
+
+ pr(FATAL,%s: stat: %s,d-d_dev,strerror(errno));
+
+#else
+# warning Unknown OS, please implement geometry probing
+
+ pr(FATAL,Cannot probe disk geometry on this system, please use -C or -g);
+
#endif
return (g);
Re: gpart FTBFS
Hi Harish, On Wed, Feb 8, 2012 at 6:44 AM, harish badrinath harishbadrin...@gmail.com wrote: Just a friendly bump :). I'll try to have a look at your work this week-end, if nobody get to it by then. (Sorry for the delay,) -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaap3ysszudy_trihknvbtnpw09rwr7_nq3xffus5+g...@mail.gmail.com
Re: suckless-tools-38 hurd patch (PATH_MAX)
2012/2/1 Tanguy LE CARROUR tanguy.lecarr...@gmail.com: Thanks, I'll do that! question: first I submit it to this list as draft and then what? Oh, sorry we didn't explain this. You need to submit a bug report to the Debian bug tracking system. Sending your draft to sub...@debian.org shoud do it, but for more information about how that works, see http://www.debian.org/Bugs/Reporting. In good time, the maintainer will review your patch themselves and (hopefully) include it in their next upload of the package. We like to do reviews here before we hit the Debian BTS to make their job easier. For instance, the memstat patch I sent few days ago hasn't been commented for days... what is the next step? Sorry about that too, I'll review your latest submission ASAP. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsabmirc0ybs+39k6+lvhwvabzyq95agtkim7uf-ooc6...@mail.gmail.com
Re: gpart FTBFS
Hi Harish, thanks for your work! On Wed, Feb 1, 2012 at 9:29 AM, harish badrinath harishbadrin...@gmail.com wrote: Hello, Any updates ?? Are people satisfied with my work ?? Probably nobody has had time yet to review your email and dig into the issue. (We're a bit short on manpower). We'll get around to it, but feel free to remind us if there's no activity after a week or so. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaaawe_+y2c2i7wwsj77vcmhm+lnmvtv8vnusmz8ka0...@mail.gmail.com
Re: Thoughts on MAXPATHLEN
On Tue, Jan 31, 2012 at 12:57 PM, Justus Winter teyth...@jade-hamburg.de wrote: Well, fixing fixed-sized buffer issues is a good exercise to improve ones c skills, but I do not see how it helps anyone to get a foot into the Hurd project if he fixed a bug in e.g. nautilus or tar. A social foot maybe, but otherwise I agree. Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Right. For what it's worth, I'm personnaly agnostic with regards to defining PATH_MAX on Hurd. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaa6g4svzjvftgg7sgpsxgc+k4rqiak3moxjajljx1f...@mail.gmail.com
Re: suckless-tools-38 hurd patch (PATH_MAX)
Hi Tanguy, On Tue, Jan 31, 2012 at 2:13 PM, Tanguy LE CARROUR tanguy.lecarr...@gmail.com wrote: Another (small) one if some of you guys have time to review some code. The patch looks good, you should submit it. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAbgn3e8G_VuqW70WbUbuCjs0a4ZqM0k=+rstsw8xkj...@mail.gmail.com
Debian GNU/Hurd mirror at jk.fr.eu.org to be discontinued
Hi everyone, Since it is no longer required for new installations, and I'm switching servers, I intend to discontinue the Debian GNU/Hurd mirror at jk.fr.eu.org. If you installed Hurd using Debian-Installer, it is possible that your /etc/apt/sources.list file still contains lines such as: deb http://jk.fr.eu.org/debian/hurd-installer/mirror unstable main deb-src http://jk.fr.eu.org/debian/hurd-installer/mirror unstable main In this case, replace them with an official Debian mirror + debian-ports. For instance: deb http://ftp.fr.debian.org/debian unstable main deb-src http://ftp.fr.debian.org/debian unstable main deb http://ftp.debian-ports.org/debian unreleased main deb-src http://ftp.debian-ports.org/debian unreleased main The mirror will be taken offline some time next week. After that, users with old sources.list entries will no longer be able to upgrade their system until they make the above modifications. If you think this is too disruptive and the mirror should stay up for the time being, please object now and I'll deploy my scripts[1] on the new server. [1] https://github.com/jeremie-koenig/hurd-installer-mirror -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaap1nfvtxtyft6hmwjhshnurrn6fh3rv5lyk8y057f...@mail.gmail.com
Re: auto-apt-0.3.22 hurd patch (PATH_MAX)
On Thu, Jan 26, 2012 at 1:21 PM, Tanguy LE CARROUR
tanguy.lecarr...@gmail.com wrote:
2) The problem in pkg_symbol() is a bit different. The dynamically allocated
buffer is the return value of the function, so I cannot free it in the
function. The rest of the code that uses this buffer never frees it!
Am I supposed to fix each part of the code that uses this function to free
the returned buffer?!
Presumably the returned buffer is static.
You could use a static pointer to a buffer which is reallocated on
each call; from the exterior the semantics would be close to
identical:
char *fun(void)
{
static char *buf = NULL;
...
buf = realloc(buf, whatever size is required this time);
...
return buf;
}
You'll be fine as long as the calling code does not assume the
function returns a constant pointer.
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CA+kCSAbd+D+bLjw=njq2cfnuaxfyoraxwknw57knwcxmowu...@mail.gmail.com
Re: memstat: FTBFS on hurd-i386
On Wed, Jan 25, 2012 at 10:33 AM, Tanguy LE CARROUR tanguy.lecarr...@gmail.com wrote: FIXME: Is it really useful to check if BUFSIZ is difined? No, here's the reference: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html [More complete reply later] -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAZDfd0b-3tOb4bzTRwuo+EN5Ec=dvcgdgoiz80n-1d...@mail.gmail.com
Re: memstat: FTBFS on hurd-i386
2012/1/25 Tanguy LE CARROUR tanguy.lecarr...@gmail.com: If it's in POSIX (any version?) we can use it without testing for its existance, is that it?! It's all relative to the target architectures for the software you're working on. But basically, yes, POSIX is the generally accepted standard. Since BUFSIZ has been in POSIX (and, I beleive, the C standards) for ages, it should be okay to use it as-is. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAYw-imGYyõmZ+0Xaªu19M2q0kC5qBhGkMR9=-n...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
Hi Tanguy, great job!
2012/1/24 Tanguy LE CARROUR tanguy.lecarr...@gmail.com:
I hope I've fixed all the bugs in my patch, but I have one last small
question: Do I really need to check if BUFSIZ is defined?
Remaining quirks that I can see:
- You can drop -lm as well, since it's no longer be required.
get_line()
- The body of the while loop should probably be indented.
- fgets(buf + last, buf_size - last, f); then you can realloc unconditionally
read_proc()
- random trick: you could substitute 'buff_size = 11' with 'buff_size
= sizeof /proc//maps' (includes the '\0'), then drop the comment [or
use Richard's version]
- _ * sizeof(char) : no need to bother, I think sizeof (char) is 1
by definition
- there is a remaining indentation problem with the first two lines in
the while() loop and in other spots, make sure you set your tabs to
print as 8 spaces.
Unnecessary/unrelated:
if (nread 7) {
fprintf(stderr, I don't recognize format of /proc/%d/maps.
(nread=%d)\n, pid, nread);
+ fclose(f);
+ closedir(d);
exit(1);
}
But aside from these minor issues and the one spotted by Richard, the
patch looks good to me.
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CA+kCSAYN3zSHN+URG43eMh8s7xCzG=o14j4-f14mnp-igo8...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
2012/1/24 Tanguy LE CARROUR tanguy.lecarr...@gmail.com:
The indentation is really strange! For example, line 112 from the original
memstat.c: (tab '--', space '.')
---if (errno != 0) {
--perror(strtol);
exit(1);
}
Does it make any sense?!
It does when tabs are displayed as 8 spaces, though it is inconsistent
wrt. some tabs being expanded as spaces.
- fgets(buf + last, buf_size - last, f); then you can realloc
unconditionally
I still need to check if the buffer size needs to be increased, or I'll
increase it each time I read a part of the line?!
if (buf_size last + BUFSIZ + 1) {
You'll double the size each time, it's okay.
This may not be a problem as line are supposed to be short and buffer is
big, but if I had a 10 char. buffer on a 1000 char. line I would end up
with a BIG buffer, wouldn't I?
1280 bytes, after 7 iterations.
I hope I've fixed everything, except for the to increase or not to increase
the buffer on each iteration in the get_line().
Looks fine,
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CA+kCSAZjt1Bfzyds6qr9UvZCK_kJoK=gn3-cr5zgfuzom7f...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
2012/1/24 Tanguy LE CARROUR tanguy.lecarr...@gmail.com: I applied the unconditional realloc()... ... I also check the return value of malloc(): Okay, good. One last minor thing: + buf_size = buf_size ? buf_size * 2 : BUFSIZ + 1; The + 1 is not necessary (consider BUFSIZ could be any value). Otherwise, the patch is great, you should submit a bug report. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaydhavukphulo+ppqbyya9thdsltzrq1mp4z5cxkbi...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
2012/1/23 Tanguy LE CARROUR tanguy.lecarr...@gmail.com: Hi Jérémie, Thanks for your comments! I'll have a look a it later this week but I've already learnt something: I'm a very bad developer! ^_^' Don't worry, portability work is harder than it looks. Also, keep in mind the whole point of patch review is to point out imperfections. But it will teach you a lot because you get to read lots of code from many different people, and your code will be read by many different people as well. Besides, as a first attempt your patch was nothing to be ashamed of! I though your log10() trick was smart, if a little bit overkill :-) -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAZpJ7O07BgkadqkNVO9=-15tyyksgznrc-aif3+_a-...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
2012/1/23 Tanguy LE CARROUR tanguy.lecarr...@gmail.com: 2012/1/22 Jérémie Koenig j...@jk.fr.eu.org The usual trick for %d is to use the constant sizeof (int) * 3 + 1. I included + 1 for the sign, but it's not really necessary if we exepect sizeof(int) = 2, which we probably should. Why '*3'? Do you expect PID to be in a certain range? Or is it C-voodoo?! log(MAX_INT) = log(2 ^ 32) = 32 * log(2) = 4 * 8 * log(2) = sizeof(int) * 2.40823997 sizeof(int) * 3 Also, I think there are some problems with your pointer arithmetic. For instance, if (fgets(buf+last,size,f) == NULL) will overwrite the last character read from the previous iteration (if there was one). According to the 'gets' page, each read returns a '\0' terminated string. Each time I get rid of this '\0' when concatenating. Terminating strings with '\0' is the standard practice in C; the string length returned by strlen() does not include the terminating nul. Last, but not least, you should be careful with whitespace. Your patch mixes tabs and spaces for indentation, ... which is perfectly consistent with the original code! ;-) Is a mix (maybe with a logic... I haven't figured it out yet) of spaces and tabs. I can try to reproduce the same pattern but not sure what the rule is! One common mixed approach is to use tabs for the initial indent and use spaces for supplementary indent when a line is broken because of a long statement. Also, I think your editor displays tabs as 4 spaces, whereas 8 spaces is a more common setting for C code. (but the above convention should ensure the code looks good regardless). I don't know what memstat uses. The code might well be inconsistent in which case you should evaluate which rule is used more often and stick to that. Bye, -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAa=Wk1-xn=hjmr7yxxtwlx0rxp6bamdfvrrgr45b56...@mail.gmail.com
Re: memstat-0.9 hurd patch (PATH_MAX)
Hi, thanks for working on this.
A couple of issues I found in your patch:
3) Fix...
a) piece of cake (TM), but include math.h (for log10() function) to get
an accurate length for the buffer... which may be an overhead!
It is indeed much trouble for very few bytes saved :-)
The usual trick for %d is to use the constant sizeof (int) * 3 +
1. I included + 1 for the sign, but it's not really necessary if we
exepect sizeof(int) = 2, which we probably should.
On the other hand, don't forget to include the byte for the
terminating '\0' in your buffer length calculations!
b) read file lines in a dynamically re-sized buffer
The usual approach is to reallocate the buffer geometrically, for instance:
size = size ? size * 2 : BUFSIZ;
This way the number of reallocations grows logarithmically rather than
linearily with the actual size we need.
Also, I think there are some problems with your pointer arithmetic.
For instance,
if (fgets(buf+last,size,f) == NULL)
will overwrite the last character read from the previous iteration (if
there was one).
In fact,
- at entry, last points to the first unused byte in your buffer (0),
- on subsequent iterations, it points the last used byte (strlen(buf) - 1).
I would say the first unused byte convention is more common and
straightforward.
Also, in:
if (buf[last+1] != '\n') { return buf; }
buf[last+1] will always be '\0' (the terminating null character of the
string). I also think you mean to return when the last character _is_
a newline (fortunately the two mistakes cancel each other out in the
usual case of no reallocation needed :-).
c) use lstat as described in readlink man page
In the error case (Cannot read link information),
- filename is used after it has been freed
- the two if() blocks could be merged as :
if (len 0 || len sb.st_size) { ... }
5) But...
- memstat uses /proc/XYZ/exe and /proc/XYZ/maps... and the output of
memstat on Hurd is different than the one on Linux
I can't test your patch right now but I'd say this is to be expected.
- implement (copy/paste mostly) a get_line function. Might have been better
to use the GNU get_line()... or not?!
The getline() function has only recently been added to POSIX, so
portability might be a problem in the short term. What you can use
generally depends on the intended target platforms for the original
code.
Last, but not least, you should be careful with whitespace. Your patch
mixes tabs and spaces for indentation, and gratuitously removes an
empty line (line 181 in the new version). This may seem trivial at
first, but it's very important for source code to be uniformly
indented, and upstream will rightfully insist that the patches you
submit respect the conventions of the original code.
Feel free to make comments on everything (code, decisions, style), I know
that I still have a lot to learn!
Don't we all? :-)
Happy hacking,
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/ca+kcsaz5vaynjcpvky6pwajub1ngmuwjpodj+0mfh2pn-+3...@mail.gmail.com
Bug#556526: hurd - FHS violation: /libexec
On Wed, Sep 7, 2011 at 11:07 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 16, 2009 at 03:40:05PM +0100, Bastian Blank wrote: Hurd violates the FHS by using /libexec. This name seems to be only used by init and /etc/ttys. I'm upgrading this to serious on the grounds that this package is only useful on the non-release architecture hurd-i386 and it's clearly a policy violation that makes the package unsuitable for a release. There's a patch here: http://lists.archhurd.org/devel/msg00102.html. The patch moves /libexec/* to /etc. I guess /sbin (or maybe, /lib/hurd) would be more appropriate. What do you think? -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsayotnzmzs4b2opo1+rhrumbg4zxhuntd_ke_a_bqtf...@mail.gmail.com
Re: [PATCH 2/2] patches/hurd-i386/submitted-hurdsig-*: Improve signals on Hurd
On Sat, Jul 23, 2011 at 8:54 AM, Jeremie Koenig j...@jk.fr.eu.org wrote: .../hurd-i386/submitted-hurdsig-SA_SIGINFO.diff | 527 + For the record, this patch makes posix/tst-waitid.c fail, because SA_SIGINFO is now defined but the information is incomplete on SIGCHLD (the sigcode is incorrect and the pid is sometimes missing), so the test in question will need to be added to the expected failures if this patch is applied. I have a hurd patch which should fix the sigcode problem in proc, but fixing the pid issue will require a new RPC to use instead of msg_sig_post so that the relevant information can be included. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsayzl0rnj4qbbrsn0mhzuwecx4o8cw00sxouww8ua+b...@mail.gmail.com
Re: Mach bug trigger: Re: Updated gdb patch
On Wed, May 18, 2011 at 11:15 AM, Svante Signell svante.sign...@telia.com wrote: On Tue, 2011-05-17 at 17:34 +0200, Svante Signell wrote: (gdb) run --version (gdb) Starting program: /usr/sbin/exim4 --version This warning disappeared: warning: Error setting exception port for process 1701: (ipc/send) invalid destination port And this console message disappears: task 520b4efc deallocating an invalid port 27260952, most probably a bug For what it's worth, I see the same behavior with gdb /bin/ps-hurd. Package versions : - gdb 7.0.1-2 - hurd 20110519-1 -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTim4RSbwoV+xUOonQE5j00vFFwR=q...@mail.gmail.com
Fwd: Bug#584538: libdebian-installer: problems on Hurd with poll()
For your information, my libdebian-installer4 patch.
-- Forwarded message --
From: Jérémie Koenig j...@jk.fr.eu.org
Date: 2010/6/4
Subject: Bug#584538: libdebian-installer: problems on Hurd with poll()
To: sub...@bugs.debian.org
Package: libdebian-installer4
Version: 0.72
Tags: patch
User: j...@jk.fr.eu.org
Usertags: gsoc2010
Hello,
On Hurd, libdebian-installer gets stuck inside the internal_di_exec()
function. This is caused by the way poll() reports end-of-file, which
cannot be portably relied on.
The attach patch uses feof() instead of POLLHUP to detect it.
Though it's somewhat unrelated, it also disables short-circuiting
doxygen on Hurd, which does not apply any more and makes the package
fail to build because of missing files in debian/tmp/usr/share/doc.
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
Index: packages/libdebian-installer/debian/control
===
--- packages/libdebian-installer/debian/control (revision 63370)
+++ packages/libdebian-installer/debian/control (working copy)
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Install System Team debian-b...@lists.debian.org
Uploaders: Bastian Blank wa...@debian.org, Colin Watson cjwat...@debian.org
-Build-Depends: dpkg-dev (= 1.13.5), debhelper (= 7.3.0~), autotools-dev, doxygen [!hurd-i386]
+Build-Depends: dpkg-dev (= 1.13.5), debhelper (= 7.3.0~), autotools-dev, doxygen
Standards-Version: 3.8.1
Vcs-Svn: svn://svn.debian.org/d-i/trunk/packages/libdebian-installer
Index: packages/libdebian-installer/debian/rules
===
--- packages/libdebian-installer/debian/rules (revision 63370)
+++ packages/libdebian-installer/debian/rules (working copy)
@@ -21,9 +21,7 @@
override_dh_auto_build:
dh_auto_build
-ifneq ($(DEB_HOST_ARCH_OS),hurd)
$(MAKE) -C build/doc doc
-endif
override_dh_clean:
ifneq $(wildcard /usr/share/misc/config.sub)
Index: packages/libdebian-installer/src/exec.c
===
--- packages/libdebian-installer/src/exec.c (revision 63370)
+++ packages/libdebian-installer/src/exec.c (working copy)
@@ -162,14 +162,12 @@
{
bool exit = false;
+/* Implementations of poll() deliver various combinations of POLLIN and
+ POLLHUP on EOF. fgets() detects it and we check with feof() below.
+ References: http://www.greenend.org.uk/rjk/2001/06/poll.html */
for (i = 0; i pipes; i++)
{
-/* References: http://www.greenend.org.uk/rjk/2001/06/poll.html */
-#if defined(__FreeBSD_kernel__)
- if ((pollfds[i].revents POLLIN) (! (pollfds[i].revents POLLHUP)))
-#else
- if (pollfds[i].revents POLLIN)
-#endif
+ if (pollfds[i].revents (POLLIN | POLLHUP))
{
while (fgets (line, sizeof (line), files[i].file) != NULL)
{
@@ -180,8 +178,8 @@
len--;
}
files[i].handler (line, len, io_user_data);
+ exit = true;
}
-exit = true;
}
}
@@ -189,7 +187,7 @@
continue;
for (i = 0; i pipes; i++)
- if (pollfds[i].revents POLLHUP)
+ if (feof(files[i].file))
exit = true;
if (exit)
Re: BusyBox on FreeBSD and Hurd
Hi Aurelien, thanks for your feedback. 2010/6/4 Aurelien Jarno aurel...@aurel32.net: (...) I have tried to build busybox, and I had to patch three parts of the code (the hackish way) to get it building. I haven't tried the result extensively, but it seems to work. I'll try to fix the build issues cleanly over the week-end. If you find the time, that would be great, but note that we could always mark the affected applets as depends on PLATFORM_LINUX in the meantime. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinbtzp2tuzsa3coc4i6isq7ne71b4nxva0ok...@mail.gmail.com
BusyBox on FreeBSD and Hurd
Hi all, My proposal[1] to port Debian-Installer to Hurd as a Google Summer of Code project has been accepted. As one of the first steps I have been working on porting BusyBox. I would like to suggest that we come up with a common set of changes for both FreeBSD and Hurd support and submit them upstream. With this in mind, I have been working against the upstream git repository, and have tried to incorporate both the previous Hurd patch[2] from Samuel Thibault and the Debian/kFreeBSD ones[3]. My changes are published on github[4]. I have backported them onto BusyBox 1.15.3 and successfully built a debian package including them on Hurd and Linux. Could you have a look and tell me what you think? In particular I have not been able to test my code on kFreeBSD yet, so any kind of report would be great. [1] http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig [2] http://people.debian.org/~sthibault/hurd-i386/ [3] http://svn.debian.org/viewsvn/d-i/people/slackydeb/kfreebsd/busybox/1.14/debian/ [4] http://github.com/jeremie-koenig/busybox-osports Quick start --- $ git clone git://github.com/jeremie-koenig/busybox-osports.git $ cd busybox-osports $ make allyesconfig $ vi .config # disable PLATFORM_LINUX, STATIC and WERROR $ make or, alternatively, $ git clone git://github.com/jeremie-koenig/busybox-osports.git $ cd busybox-osports $ git checkout osports-debian $ fakeroot debian/rules binary Summary --- I list my changes below. The related kFreeBSD patches are shown within square brackets. I took the approach of defining a new configuration option (PLATFORM_LINUX) that the Linux-specific applets can depend on. This way only a minimal amount of configuration overriding has to take place for Hurd and FreeBSD in the debian package. Some patches have been already included upstream: fbedacf Hurd compat fixes. Mostly dealing with absent PATH_MAX [libbb.xconnect.diff] 3d0e779 libbb: locate PAGE_SIZE on Hurd 1d448cf provide safe_gethostname() for non-linux systems [libbb.safe_gethostname.diff] The rest is in the 'osports' branch in the github repository: 9a47e16 update scripts/kconfig/*_shipped 81f0baa readlink: use xmalloc_realpath() 92fbcd8 mark Linux-specific configuration options 7a23db4 init,loginutils: termios portability fixes fa5c73c init,halt: portability improvements [init.init.diff] 250e48a init: make the initial $TERM value configurable b5065d9 libbb.h: add device names for Hurd and FreeBSD [include.libbb.diff] 3b6b59b mkdir: fix -p on FreeBSD [libbb.make_directory.diff] 7317803 klogd: support /dev/klog in addition to klogctl() [klogd.diff] 8749e88 libbb: conditionalize AF_* usage in error reporting 19efa4d stty: fix undefined IDX_* on missing termios constants c835163 cttyhack: serial console detection is Linux-specific [shell.cttyhack.diff] /!\ The serial console detection is just dropped 73a49cc bootchartd: mounting tmpfs is Linux-specific fd2a956 tcpsvd,udpsvd: conditionalize usage of SO_ORIGINAL_DST 2f6b52d vlock: disable linux console calls on other systems Stuff I will be working on soon: * mount/umount FreeBSD: [mount_with_hack_to_help_umount.diff] [util-linux.umount.diff] Hurd: issue a 'settrans' command * swapon/swapoff: FreeBSD: [util-linux.swaponoff.diff] Hurd: to be investigated Branches * osports: the main branch, based on upstream's 'master' branch; * osports-1.15.3: the same changes, rebased onto BusyBox 1.15.3; * osports-debian: a preliminary debian package including them. (we still need to somehow set INIT_TERMINAL_TYPE) Thanks, -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiklxcddtab0vtn1xdwxz0c64gdxepdmtxqej...@mail.gmail.com
genext2fs: new patches for Hurd support
user j...@jk.fr.eu.org
usertags 562999 gsoc2010
thanks
Hello,
The attached patches, based on the earlier one from Samuel Thibault,
add support for all the ext2 block sizes (1024, 2048 and 4096) to
genext2fs, and set the creator-os field of the superblock to an
appropriate value.
I have fixed a few problems with the block bitmaps which appear on
2048 and 4096 bytes blocks, related to the fact that the bootloader
area and superblock share the first block in these cases. Also, in
order to allow the block size to be chosen at runtime, I have has to
change the way the group descriptors are accessed (they cannot be kept
inside the 'filesystem' structure since their offset depends on the
block size).
The -B block size and -o creator options can be used to specify
the respective value. The last patch updates the test suite to reflect
these changes.
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
From 61859664620308e43168b91cc6ec6ed6ecae0ea7 Mon Sep 17 00:00:00 2001
From: Jeremie Koenig j...@jk.fr.eu.org
Date: Tue, 25 May 2010 16:32:53 +0200
Subject: [PATCH 1/5] Support block sizes 1024
The 'filesystem' structure is adapted to support arbitrary block sizes,
and the allocation code is fixed to handle first_data_block being 0.
---
genext2fs.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/genext2fs.c b/genext2fs.c
index f0d797d..73c4eb1 100644
--- a/genext2fs.c
+++ b/genext2fs.c
@@ -571,16 +571,15 @@ typedef struct
/* Filesystem structure that support groups */
-#if BLOCKSIZE == 1024
typedef struct
{
- block zero;// The famous block 0
- superblock sb; // The superblock
+ uint8 zero[1024]; // Room for bootloader stuff
+ superblock sb; // The superblock, always at 1024
+#if BLOCKSIZE 2048
+ uint8 zero2[BLOCKSIZE - 2048]; // align group descriptor on block size
+#endif
groupdescriptor gd[0]; // The group descriptors
} filesystem;
-#else
-#error UNHANDLED BLOCKSIZE
-#endif
// now the endianness swap
@@ -886,7 +885,7 @@ alloc_blk(filesystem *fs, uint32 nod)
error_msg_and_die(group descr %d. free blocks count == 0 (corrupted fs?),grp);
if(!(fs-sb.s_free_blocks_count--))
error_msg_and_die(superblock free blocks count == 0 (corrupted fs?));
- return fs-sb.s_blocks_per_group*grp + bk;
+ return fs-sb.s_first_data_block + fs-sb.s_blocks_per_group*grp + (bk-1);
}
// free a block
@@ -1946,10 +1945,14 @@ init_fs(int nbblocks, int nbinodes, int nbresrvd, int holes, uint32 fs_timestamp
*/
min_nbgroups = (nbinodes + INODES_PER_GROUP - 1) / INODES_PER_GROUP;
+ /* On filesystems with 1k block size, the bootloader area uses a full
+ * block. For 2048 and up, the superblock can be fitted into block 0.
+ */
+ first_block = (BLOCKSIZE == 1024);
+
/* nbblocks is the total number of blocks in the filesystem.
* a block group can have no more than 8192 blocks.
*/
- first_block = (BLOCKSIZE == 1024);
nbgroups = (nbblocks - first_block + BLOCKS_PER_GROUP - 1) / BLOCKS_PER_GROUP;
if(nbgroups min_nbgroups) nbgroups = min_nbgroups;
nbblocks_per_group = rndup((nbblocks - first_block + nbgroups - 1)/nbgroups, 8);
@@ -1961,10 +1964,10 @@ init_fs(int nbblocks, int nbinodes, int nbresrvd, int holes, uint32 fs_timestamp
gdsz = rndup(nbgroups*sizeof(groupdescriptor),BLOCKSIZE)/BLOCKSIZE;
itblsz = nbinodes_per_group * sizeof(inode)/BLOCKSIZE;
overhead_per_group = 3 /*sb,bbm,ibm*/ + gdsz + itblsz;
- if((uint32)nbblocks - 1 overhead_per_group * nbgroups)
- error_msg_and_die(too much overhead, try fewer inodes or more blocks. Note: options have changed, see --help or the man page.);
- free_blocks = nbblocks - overhead_per_group*nbgroups - 1 /*boot block*/;
+ free_blocks = nbblocks - overhead_per_group*nbgroups - first_block;
free_blocks_per_group = nbblocks_per_group - overhead_per_group;
+ if(free_blocks 0)
+ error_msg_and_die(too much overhead, try fewer inodes or more blocks. Note: options have changed, see --help or the man page.);
if(!(fs = (filesystem*)calloc(nbblocks, BLOCKSIZE)))
error_msg_and_die(not enough memory for filesystem);
@@ -1986,7 +1989,7 @@ init_fs(int nbblocks, int nbinodes, int nbresrvd, int holes, uint32 fs_timestamp
fs-sb.s_lastcheck = fs_timestamp;
// set up groupdescriptors
- for(i=0, bbmpos=gdsz+2, ibmpos=bbmpos+1, itblpos=ibmpos+1;
+ for(i=0, bbmpos=first_block+1+gdsz, ibmpos=bbmpos+1, itblpos=ibmpos+1;
inbgroups;
i++, bbmpos+=nbblocks_per_group, ibmpos+=nbblocks_per_group, itblpos+=nbblocks_per_group)
{
--
1.7.1
From 2e8251cfe728f2294da4a9257fab122ea1c40ec9 Mon Sep 17 00:00:00 2001
From: Jeremie Koenig j...@jk.fr.eu.org
Date: Tue, 25 May 2010 16:33:12 +0200
Subject: [PATCH 2/5] Make BLOCKSIZE a global variable
Since BLOCKSIZE is no longer a constant, the 'block' type cannot be a
table anymore and has been redefined as a pointer instead.
Also, group descriptors are aligned to the (now variable) block size,
so they have been removed from
Hurd Debian-Installer: roadmap, tracking progress with the BTS
Hello, Starting today I will be working on a native Hurd debian-installer. This is a Google Summer of Code project mentored by Samuel Thibault. My original proposal is there[1], and I will be updating a roadmap[2] page as I go. Of course I would welcome any kind of feedback about them at any point. [1] http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig [2] http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig/Roadmap I would also welcome suggestions about using the BTS to track my progress. If I understand correctly, I could: * track the bugs which I work on with a usertag * pre-file wishlist bugs on the packages which I will need to change * have a toplevel Hurd d-i bug which is blocked by said bugs The kind of bugs I would be filing/tagging at first would be: * debian-installer: native Hurd debian-installer * busybox: Hurd support (see also #323670) * genext2fs: support tuning the block size and creator OS (#562999) * gnumach: initrd support * ... More would be filed (especially against installer components) as I progress. Would this be appropriate? -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikamo9kdb-dxgk1ro1kep_dnagvnzvfqkomh...@mail.gmail.com
Re: Debian-installer on Debian GNU/Hurd as a GSoC project
2010/3/19 Jérémie Koenig j...@jk.fr.eu.org: I intend to apply as a GSoC student for porting debian-installer to the Hurd. Hi everyone, I just wanted to mention that I have posted my proposal on the wiki: http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig Of course I would glad to discuss it with anyone interested and would welcome any kind of feedback. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j2y24faa1cf1004061838x7ecba489p959180978cce2...@mail.gmail.com
Bug#576519: hurd: /hurd/ext2fs crashes on startup
Package: hurd Version: 20090404-2 Tags: patch Sometimes ext2fs crashes on startup, see http://richtlijn.be/~larstiq/hurd/hurd-2010-04-04: 22:58:10 jkoenig there's a bug in debian/patches/ext2fs_large_stores.patch, which makes it crash on startup 22:58:34 jkoenig namely, in get_hypermetadata() the buffer length is passed uninitialized to store_read() On my system, the problem can be reproduced by using ext2fs on a file (see the attached typescript). Initializing 'read = 0;' before the call to store_read() fixes it. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ Script started, file is typescript j...@trichome:~$ dd if=/dev/zero bs=4096 count=1000 of=test.ext2 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 5.58 s, 734 kB/s j...@trichome:~$ mkfs -o hurd -b 4096 test.ext2 mke2fs 1.41.11 (14-Mar-2010) test.ext2 is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Hurd Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 1024 inodes, 1000 blocks 50 blocks (5.00%) reserved for the super user First data block=0 1 block group 32768 blocks per group, 32768 fragments per group 1024 inodes per group Writing inode tables: 0/1done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 35 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. j...@trichome:~$ settrans -ac test /hurd/ext2fs test.ext2 settrans: /hurd/ext2fs: Translator died j...@trichome:~$ exit Script done, file is typescript
Re: [Soc-coordination] Debian-installer on Debian GNU/Hurd as a GSoC project
Hello, On Fri, Mar 19, 2010 at 1:41 AM, Samuel Thibault sthiba...@debian.org wrote: Jérémie Koenig, le Fri 19 Mar 2010 01:28:59 +0100, a écrit : (...) Maybe you could send me your patch so I can start from there / polish them ? As mentioned in the proposal it's along the rest of my d-i work in http://people.debian.org/~sthibault/hurd-i386/ Thanks for the link, sorry I missed it. I just wanted to report that I have a series of clean patches against the upstream busybox git repository which make it build on the Hurd with the attached minimal config (which is debian/config/udeb, minus ip, route, free, klogd, mount, swaponoff and pivot_root I think.) In my excitement I have already submitted them upstream [1] for review, though on second thought I understand that posting them here first would have been more appropriate, especially since you had already started working on this. [1] http://lists.busybox.net/pipermail/busybox/2010-March/071942.html Anyway, my plan right now would be: * port more applets * modify the Debian package to allow arch-specific .config files/overrides, * submit the whole lot as a wishlist bug against busybox and discuss it on debian-boot Does this sound like a reasonable course of action? -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/24faa1cf1003241249k118f05fau759070b5b5c9a...@mail.gmail.com
Debian-installer on Debian GNU/Hurd as a GSoC project
Hello, sorry for the cross-post (I couldn't quite decide...) I intend to apply as a GSoC student for porting debian-installer to the Hurd. I've started tinkering with busybox, as suggested on the ideas pages, and I will try to come up with a reasonably precise roadmap of the work needed in the coming weeks (I will post again on debian-boot and/or debian-hurd to request feedback when I do). Unless I'm mistaken, Samuel Thibault has already done some work and would be interested in mentoring such a project. I understand this is a difficult project which involves a lot of things, however I have used the Hurd and done some debian-installer work in the past. I find the design of both to be rather elegant and I'd be delighted to have the opportunity to work on them full-time this summer. One question I have is about what organization I should submit my application to. Both Debian and GNU have been accepted by Google as mentoring organizations, and I beleive Hurd will participate as a GNU project, as they did in the previous years. Would it be appropriate to apply to both? (after all, who am I to deny either of them a chance to accept my application :-P) Of course I'd also be interested in any advice you would care to give me and I would be glad to answer any question you may have. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/24faa1cf1003181615h5d911738y8c2d57da86dd...@mail.gmail.com
Re: [Soc-coordination] Debian-installer on Debian GNU/Hurd as a GSoC project
On Fri, Mar 19, 2010 at 12:45 AM, Colin Watson cjwat...@debian.org wrote: On Fri, Mar 19, 2010 at 12:15:15AM +0100, Jérémie Koenig wrote: (...) Samuel Thibault has already done some work and would be interested in mentoring such a project. I'm glad to see this. I mentored a failed project to do this a few years ago; I would be very pleased to see one succeed. Oh, I wasn't aware of this -- sorry I didn't mention you. I'll be sure to review your work. (If you want the details of that project - I'd done some work on it previously, and written up where I got stuck, which provided a partial basis for the student's work - I'd be happy to go and dig them out.) I'd be very grateful if you could do this. (but don't burry yourself :-) -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/24faa1cf1003181709l5bea1c29ib2323be171c1...@mail.gmail.com
Re: [Soc-coordination] Debian-installer on Debian GNU/Hurd as a GSoC project
On Fri, Mar 19, 2010 at 12:28 AM, Samuel Thibault sthiba...@debian.org wrote:
(...)
Jérémie Koenig, le Fri 19 Mar 2010 00:15:15 +0100, a écrit :
I've started tinkering with busybox, as suggested on the ideas pages,
Ok, I realize I have forgotten to mention that I have already patched it
to get the .debs/udebs built (very crude patch). Of course, more work
is needed to re-enable the tools that will be needed during d-i.
I've only gotten as far as de-PATH_MAXing kconfig for now (patch
attached, for what it's worth). Maybe you could send me your patch so
I can start from there / polish them ?
(...)
Don't hesitate to come on both #hurd (freenode) and #debian-hurd (oftc).
Ok, I'll meet you there!
--
Jérémie Koenig j...@jk.fr.eu.org
http://jk.fr.eu.org/
Index: busybox-1.15.3/scripts/basic/fixdep.c
===
--- busybox-1.15.3.orig/scripts/basic/fixdep.c 2009-12-12 02:45:09.0 +0100
+++ busybox-1.15.3/scripts/basic/fixdep.c 2010-03-13 14:28:48.0 +0100
@@ -203,7 +203,7 @@
*/
void use_config(char *m, int slen)
{
- char s[PATH_MAX];
+ char *s = alloca(slen+1);
char *p;
if (is_defined_config(m, slen))
@@ -310,7 +310,7 @@
char *m = map;
char *end = m + len;
char *p;
- char s[PATH_MAX];
+ char *s = alloca(len);
p = memchr(m, ':', len);
if (!p) {
Index: busybox-1.15.3/scripts/kconfig/confdata.c
===
--- busybox-1.15.3.orig/scripts/kconfig/confdata.c 2009-12-12 02:45:09.0 +0100
+++ busybox-1.15.3/scripts/kconfig/confdata.c 2010-03-13 14:28:48.0 +0100
@@ -70,12 +70,13 @@
char *conf_get_default_confname(void)
{
struct stat buf;
- static char fullname[PATH_MAX+1];
+ static char *fullname = NULL;
char *env, *name;
name = conf_expand_value(conf_defname);
env = getenv(SRCTREE);
if (env) {
+ fullname = realloc(fullname, strlen(env) + strlen(name) + 2);
sprintf(fullname, %s/%s, env, name);
if (!stat(fullname, buf))
return fullname;
Index: busybox-1.15.3/scripts/kconfig/mconf.c
===
--- busybox-1.15.3.orig/scripts/kconfig/mconf.c 2009-12-12 02:45:09.0 +0100
+++ busybox-1.15.3/scripts/kconfig/mconf.c 2010-03-13 14:28:48.0 +0100
@@ -258,7 +258,7 @@
static char buf[4096], *bufptr = buf;
static char input_buf[4096];
-static char filename[PATH_MAX+1] = .config;
+static const char *filename = .config;
static char *args[1024], **argptr = args;
static int indent;
static struct termios ios_org;
Index: busybox-1.15.3/scripts/kconfig/zconf.l
===
--- busybox-1.15.3.orig/scripts/kconfig/zconf.l 2009-12-12 02:45:09.0 +0100
+++ busybox-1.15.3/scripts/kconfig/zconf.l 2010-03-13 14:28:48.0 +0100
@@ -265,13 +265,14 @@
*/
FILE *zconf_fopen(const char *name)
{
- char *env, fullname[PATH_MAX+1];
+ char *env, *fullname;
FILE *f;
f = fopen(name, r);
if (!f name[0] != '/') {
env = getenv(SRCTREE);
if (env) {
+ fullname = alloca(strlen(env) + strlen(name) + 2);
sprintf(fullname, %s/%s, env, name);
f = fopen(fullname, r);
}
Index: busybox-1.15.3/scripts/basic/docproc.c
===
--- busybox-1.15.3.orig/scripts/basic/docproc.c 2010-03-13 14:33:49.0 +0100
+++ busybox-1.15.3/scripts/basic/docproc.c 2010-03-13 14:33:56.0 +0100
@@ -79,7 +79,9 @@
{
pid_t pid;
int ret;
- char real_filename[PATH_MAX + 1];
+ char *real_filename;
+ int rflen;
+
/* Make sure output generated so far are flushed */
fflush(stdout);
switch(pid=fork()) {
@@ -87,10 +89,11 @@
perror(fork);
exit(1);
case 0:
- memset(real_filename, 0, sizeof(real_filename));
- strncat(real_filename, getenv(SRCTREE), PATH_MAX);
- strncat(real_filename, KERNELDOCPATH KERNELDOC,
- PATH_MAX - strlen(real_filename));
+ rflen = strlen(getenv(SRCTREE));
+ rflen += strlen(KERNELDOCPATH KERNELDOC);
+ real_filename = malloc(rflen + 1);
+ strcpy(real_filename, getenv(SRCTREE));
+ strcat(real_filename, KERNELDOCPATH KERNELDOC);
execvp(real_filename, svec);
fprintf(stderr, exec );
perror(real_filename);
@@ -166,11 +169,10 @@
struct symfile *sym;
char line[MAXLINESZ];
if (filename_exist(filename) == NULL) {
- char real_filename[PATH_MAX + 1];
- memset(real_filename, 0, sizeof(real_filename));
- strncat(real_filename, getenv(SRCTREE), PATH_MAX);
- strncat(real_filename, filename,
-PATH_MAX - strlen(real_filename));
+ int rflen = strlen(getenv(SRCTREE)) + strlen(filename);
+ char *real_filename = alloca(rflen + 1);
+ strcpy(real_filename, getenv(SRCTREE));
+ strcat(real_filename, filename);
sym = add_new_file(filename);
fp = fopen(real_filename, r);
if (fp == NULL)
Index: busybox-1.15.3/scripts/kconfig/Makefile
