Re: Rework of the userspace interrupt handling patch
Hi Justus El 28/02/16 a les 00:33, Justus Winter ha escrit: > This requires a tiny change to libddekit. I'll send it as a > follow-up. With it libddekit supports both the new and old kind of > notification to make upgrades painless. This sounds like it could affect the implementation in Rump, which is partly based on libddekit. Did you take this into account? See the code in: https://github.com/rumpkernel/pci-userspace/blob/master/src-gnu/pci_user-gnu.c#L169 and precompiled testcase in: https://people.debian.org/~rmh/rump/apt/ Thanks! -- Robert Millan
Fwd: looking back at 2015
FYI, some Hurd mention in Rumpkernel's yearly report Missatge reenviat Assumpte: looking back at 2015 Data: Fri, 15 Jan 2016 15:30:50 + De: Antti Kantee Respon a: po...@rumpkernel.org A: rumpkernel-users Hello, and a belated welcome to 2016, As people who've been on the list for a while know, the visions & roadmap mail comes during summer, simply because it's nicer to think about those things while sitting outside enjoying sunny weather. In this mail we look back at 2015, if only to give an excuse to write light prose for Friday afternoon delight. For the rump kernel project, 2015 was undoubtedly dominated by the unikernel use case. Thinking back, at the beginning of 2015 only Martin and myself were regularly contributing to the Rumprun unikernel (*). Now we have at least a dozen people contributing more or less regularly (**), especially as maintainers for rumprun-packages. What has been especially nice to see is that folks don't only contribute new packages, they also stick around and maintain them. Those who've been following my rants know that I think making something maintainable and maintaining it is much more demanding than just whipping something up and forgetting about it. It's also harder to find motivation for maintenance, at least unless you have non-academic real world interest in keeping the subject matter afloat. A big thanks goes to the contributors of the packaging exploration/effort. *) back then, the Rumprun repository as we know it now didn't even exist, it still existed as two separate repositories named rumprun-xen and rumprun-baremetal. In fact, for all I remember, we didn't even market those as unikernels back then. Their unification surely improved my mental stability, and starting to call the result a unikernel also shows how far unikernels came as a global concept in the past year. **) As of writing this, the rumpkernel project on github has 23 members, which means that 23 internet beings -- most of them probably human -- have push access to at least one repository under repo.rumpkernel.org Now, while unikernels are the proverbial Soviet space pencil, if you want to create a hardcopy of War and Peace, you'll most likely want to reach for some other tool. The folks who brought balance to the Source by improving a different type of tool was the HURD microkernel project. They became, to the best of my knowledge, the first folks outside of rumpkernel.org to incorporate PCI device drivers provided by rump kernels into their system. Again, it was not idle academic curiosity, but rather solving a real problem for their system. Nicely done! On the documentation front, the wiki received improvements from a wide number of people. A few even contributed brand new articles. Writing documentation is harder than writing code, since it has to be written against non-exact and not-well-defined human parsers. That difficulty is why it is very important to get a breadth of people contributing to the docs. Many thanks go to those who have chipped in on that front. If you think there was some other significant type of 2015 happening which failed to surf my brain waves, please do share. This year, unikernels will probably go even further. And I will be sitting here as the grey lord (***) making sure things are in balance for all uses of rump kernels. Please keep pouring them in. - antti ***) knowledge of Dungeon Master is also a definite requirement for literacy on this list. wonder if that should be in the FAQ.
Re: licensing of intloop() in libddekit/interrupt.c
El 30/11/15 a les 23:20, Olaf Buddenhagen ha escrit: > Hi Robert, > > On Sun, Nov 08, 2015 at 09:39:49PM +0100, Robert Millan wrote: > >> I have thus merged the remaining bits of GNU/Hurd port > [...] >> with this commit the port is now complete. > > Great! :-) > > I was wondering, now that this part is done, whether you intended also > to work on the next steps towards integrating Rump drivers in the Hurd? Maybe, if time permits. Can't promise anything though :-( Note that my Rump packages haven't made it into Debian yet... -- Robert Millan
Re: licensing of intloop() in libddekit/interrupt.c
El 10/11/15 a les 14:24, Antti Kantee ha escrit: > On 08/11/15 20:39, Robert Millan wrote: >> El 08/11/15 a les 20:45, Da Zheng ha escrit: >>> Hello Robert, >>> >>> Sure, I have no problem with the license. >> >> Excellent! >> >> I have thus merged the remaining bits of GNU/Hurd port which included your >> code: >> >> >> https://github.com/rumpkernel/pci-userspace/commit/a9202c047ff191c752d62c1d03c843f1737c33ba >> >> with this commit the port is now complete. Many thanks :-) > > Great that something around here is complete ;) > > Is it possible to easily make Travis CI build test that implementation? Not that I know of. But I've seen some Jenkins-based testing for the Hurd by lurking on this list: https://jenkins.debian.net/job/g-i-installation_debian_jessie_hurd_lxde/66/ Since all the relevant lists are CCed, chances are someone with better knowledge can follow up :-) -- Robert Millan
Re: licensing of intloop() in libddekit/interrupt.c
El 08/11/15 a les 20:45, Da Zheng ha escrit: > Hello Robert, > > Sure, I have no problem with the license. Excellent! I have thus merged the remaining bits of GNU/Hurd port which included your code: https://github.com/rumpkernel/pci-userspace/commit/a9202c047ff191c752d62c1d03c843f1737c33ba with this commit the port is now complete. Many thanks :-) -- Robert Millan
Re: licensing of intloop() in libddekit/interrupt.c
Hi! El 08/11/15 a les 20:12, Da Zheng ha escrit: > Sorry for disappearing for years. Never mind, nice hearing from you :-) > Is there anything I can do for you? Sure thing. I guess you're busy so I'll be brief: I ported Rump (http://rumpkernel.org/) to GNU/Hurd. In order to access hardware from user-space just like DDE does, I reused some code of yours. Specifically, I used code from your intloop() function in libddekit/interrupt.c (see [1]). Would you agree to license that code under a permissive license so that we can merge it into mainstream Rump? The following are the license terms used in other parts of Rump. If you would like to use these terms, just say so by replying publicly in this thread and I'll take care of the rest (or if you have other license in mind, please let us know as well). - * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. - Many thanks [1] The copyright-significant bits which have actually been used in my work are: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=8a1bc5a21ade1a3aeedbb552315ff1ed5da6d7aa https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=40bd937d601627bc9604c5d7d8c528643358b3a7 https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=dcd71f277d3fa4615b86e772a4f649d25981dd02 https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=63e2a076f77620867d80500b1510f70f5e093a82 https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=92e2538dd9825f83d8f961fe85630ebe0bfd4f40 https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=2727b6bd16489e8592d3b45faee1f42c00ce2804 https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=8a4668dfd4106f26bf5bf6ed69717eb06a3628db https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=1c5442e1fc9d4dfc71c7ce20900436897afcabf8 -- Robert Millan
Re: licensing of intloop() in libddekit/interrupt.c
Apologies, I forgot to CC bug-hurd. El 07/11/15 a les 12:11, Robert Millan ha escrit: > > Unfortunately I didn't get any reply from Zheng Da. Does someone know if > Zheng is > using another email address nowadays? > > In case he can't be reached anymore, I traced origin of the intloop() routine > and > found that: > > 0. The copyright header in interrupt.c mentions Thomas Friebel > >and Christian Helmuth as authors, however this > doesn't >affect the code I'm importing (see #2). > > 1. The copyright-significant bits which have actually been used in my work are > exclusively made of code committed to Debian hurd.git: > > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=8a1bc5a21ade1a3aeedbb552315ff1ed5da6d7aa > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=40bd937d601627bc9604c5d7d8c528643358b3a7 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=dcd71f277d3fa4615b86e772a4f649d25981dd02 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=63e2a076f77620867d80500b1510f70f5e093a82 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=92e2538dd9825f83d8f961fe85630ebe0bfd4f40 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=2727b6bd16489e8592d3b45faee1f42c00ce2804 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=8a4668dfd4106f26bf5bf6ed69717eb06a3628db > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=1c5442e1fc9d4dfc71c7ce20900436897afcabf8 > > 2. Initial commit by Zheng (6f5290eeb41219ea8b81f6df3ffceb0f4614cdd1) is an > import commit >and includes code written by others, however none of the code in that > commit is included >in my work (since I'm only interested in the GNU Mach interaction bits > which were added >after that). > > 3. The remaining (Samuel's) commits affecting this routine are trivial > renames, not significant >for copyright purposes: > > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=56b24422cad2f61ca9d1456e3cf755f53809caa3 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=321bb5dac2409552cf3db5bce8f9462a45cbcf5d > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=2f7814d3d8b629c85e3ea0d9f12f6d2a8daab931 > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=6d61151e937510dcb7a4977975bb750eb7ae624c > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-hurd/hurd.git;a=commit;h=22481555a880bb5fe3b87b6f6fd74ed58fa91e7f > > With this we have "Copyright (C) 2009, 2010 Zheng Da", but still no licensing > information. > > Since Zheng committed it to pkg-hurd, I understand it's common convention to > assume > Zheng's code is licensed under the same terms? > > Unfortunately this gets a bit confusing: some parts of the Hurd are GPLv2 and > some are GPLv2+. > Then the file Zheng was modifying [1] is imported from DDE/L4 which is GPLv2 > [2]. > > [1] http://svn.tudos.org/repos/tudos/trunk/l4/pkg/dde/ddekit/src/interrupt.c > [2] http://svn.tudos.org/repos/tudos/trunk/l4/pkg/COPYING > > What should we make of this? It's somewhat relevant as the code will be > linked into librumpdev_pci, > which in turn will be linked by its final users in the application layer. > > Please advise... > > El 16/08/15 a les 22:33, Robert Millan ha escrit: >> >> Hi Zheng Da, >> >> First of all, allow me to show you my appreciation for your effort on >> integrating >> DDE with the Hurd. The groundwork on creating facilities that enable >> userspace >> drivers has been greatly helpful on this little project of mine. >> >> Just to put you in context, I've ported Rump (http://rumpkernel.org/) to >> GNU/Hurd >> and written some extensions that allow it to run its own PCI drivers in >> userspace. >> >> For that I used the same facilities in Gnu Mach that libddekit is using, and >> also >> imported some the code in libddekit for userspace interrupt management. Olaf >> (see >> below) believes that this code was written by you: >> >> El 16/08/15 a les 21:02, Olaf Buddenhagen ha escrit: >>> On Sun, Aug 16, 2015 at 01:09:59PM +0200, Robert Millan wrote: >>> >>>> * It includes code from other people under GPLv2; >>> >>>>- intrth
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
El 13/09/15 a les 14:55, Antti Kantee ha escrit: > On 13/09/15 09:33, Robert Millan wrote: >> Hi Antti >> >> El 31/08/15 a les 21:05, Antti Kantee ha escrit: >>> On 31/08/15 14:30, Robert Millan wrote: >>>> El 31/08/15 a les 16:04, Robert Millan ha escrit: >>>>> I had some trouble with the .BEGIN approach, but the MAKEFILEINC one >>>>> works >>>>> perfectly. I'm attaching a patch. >>>> >>>> Actually, please use this one, which includes .ifdef not to break other >>>> platforms ;-) >>> >>> Yea I'll probably add something like that, but need to think about it >>> a bit more first, namely why didn't I do that originally. Either I >>> was being stupid, or there was some actual reason. I'll let you >>> know. Use the .BEGIN way for now if you can make it work (or drag the >>> local patch for a few days). >> >> Hereby, a kind reminder :) > > Yea it's being worked on. I want to split the bus dma/space routines out of > libpci, since they shouldn't be there, plus add some necessary parameters to > the hypercalls (e.g. memory alignment/boundary requirements). I think it's > good to get that done before you start depending on anything. So I'll just > bundle the Makefile change in with the other changes. Just to make sure you don't forget ;-) Kindly, -- Robert Millan
Re: libusb+librump patch
El 15/10/15 a les 03:03, Bruno Félix Rezende Ribeiro ha escrit:
OTOH I think this part of your patch:
+ #define RUMP_SYS_OPEN
+ #define RUMP_SYS_CLOSE
+ #define RUMP_SYS_IOCTL
+ #define RUMP_SYS_READWRITE
is a bit dangerous. It would break any (current or future) usage of
open() / close() / etc in that file which is not related to USB device
nodes.
I see. What do you recommend? #ifdefs for each occurrence? Anyway,
I'm just playing around with it.
I recommend explicit rump_sys_open(), e.g.
int fd = rump_sys_open("/dev/ugenhc", RUMP_O_RDWR);
if (fd == -1)
error(1, rump_errno2host(errno), "rump_sys_open");
--
Robert Millan
Re: libusb+librump patch
Hi Bruno, El 30/09/15 a les 06:57, Bruno Félix Rezende Ribeiro ha escrit: To test the built library, build the example application and run it. $ cd examples && make $ su -c './listdevs' Now, here is the problem: When I run 'listdevs' with no USB device connected to the box I get: libusb: 0.00 debug [libusb_init] libusb-1.0.9 libusb: 1.87 debug [usbi_add_pollfd] add fd 4 events 1 libusb: 1.87 debug [libusb_init] created default context libusb: 1.88 debug [libusb_get_device_list] libusb: 1.88 debug [obsd_get_device_list] libusb: 1.91 debug [libusb_exit] libusb: 1.91 debug [libusb_exit] destroying default context libusb: 1.92 debug [usbi_remove_pollfd] remove fd 4 And thus no device is listed, as expected. However, if I plug in any USB device I get the following message after the first (libusb_init) line: WARNING: 1 error while detecting hardware; check system log. It means that this message is produced by the 'rump_init' function. The other debug messages are the same, and thus no device is listed --- what's not right. Do you have any idea on what's going on? Any points to facts, procedures, concepts or documentation will be highly appreciated. I suggest you export RUMP_VERBOSE=2 to get verbose output from the Rump kernel. OTOH I think this part of your patch: + #define RUMP_SYS_OPEN + #define RUMP_SYS_CLOSE + #define RUMP_SYS_IOCTL + #define RUMP_SYS_READWRITE is a bit dangerous. It would break any (current or future) usage of open() / close() / etc in that file which is not related to USB device nodes. Best regards -- Robert Millan
Re: Shortest path to significant improvement in hardware support
Hi Bruno! El 29/09/15 a les 11:31, Bruno Félix Rezende Ribeiro ha escrit: My main goal working on Hurd is to get more people to use the GNU system, so we can achieve critical mass to make the system develop at an acceptably pace. In order to solve this problem it's necessary to fix the most prominent issue preventing people from migrating to it, that is, its lack of hardware support. Thus, in order to form an wider user-base as soon as possible, we need to improve Hurd's hardware support using the shortest (thus fastest) path available. For that goal's sake alone, in principle, it doesn't matter the technicalities of a particular implementation, as long as it works for the majority of use cases, it's quick to implement and easy to maintain. From that perspective I'm looking for the most straightforward way to get hardware working on Hurd --- primarily USB as it seems that it along with sound (Robert Millan's work) is what people need most. After some thought I came to the conclusion that the way to achieve these requirements is to patch core libraries like libusb to use librump directly, analogously to what Robert Millan did originally for mplayer and sound support. This way we don't have to make the settlement of wonders about "the (elegant and powerful) true Hurdish way" become a dependency of the actual hardware support the Hurd community needs so badly. What are your thoughts on that? When you say USB is one of the things people need most, are you thinking on any particular usage of USB? I.e. any device class in particular? A combination of them? I recall in earlier talk about USB we discussed about possible design options my understanding from that discussion is that there were basically three possible desirable goals: #1 multiplexing (multiple processes simultaneously using USB devices) #2 authorization (allowing unprivileged users without I/O capability) #3 compatibility with non-Rump users (e.g. CUPS or SANE) Note that if you simply patch libusb to start a Rump instance all by itself, you're giving up on goals #1 and #2. However you retain goal #3. Is this something you were already contemplating? Note that retaining goals #1 and #2 is not difficult, it just means adding a translator process to sit in-between and forward ioctls to Rump. The upside is that this is *exactly* the same thing that is missing for sound, so one could kill two birds with a single stone this way. -- Robert Millan
Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c
Hi Antti, Adding bug-hurd to CC since some of the issues may concern them. El 24/09/15 a les 16:02, Antti Kantee ha escrit: On 24/09/15 10:43, Robert Millan wrote: FYI: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50276 If Hurd soundcard.h is missing those defines, doesn't it mean that some ossaudio programs will fail to compile on Hurd? Note that most of the defines are missing on Linux too (the only exception being SNDCTL_DSP_MAPINBUF and SNDCTL_DSP_MAPOUTBUF). Aside from SNDCTL_DSP_MAPINBUF/SNDCTL_DSP_MAPOUTBUF potentially being an issue with Hurd version of , the problem is not with applications but with compiling ossaudio.c itself. Why isn't adding the missing defines to the Hurd soundcard.h possible? Not just possible but also desirable IMHO. My point however isn't about running libossaudio in a specific OS, but rather that since libossaudio is now potentially usable on just about every system that could run Rump, I think it makes sense to make libossaudio more portable in general. However if you disagree about that goal, it's no big deal. Users of this stack can keep using it and carry the patches if needed. The ABI used by old binaries will not change if you add new definitions, so I'm not sure I understand your motivation for patching NetBSD sources here. Please also note that sys/soundcard.h is a vendor supplied header. Although on Hurd I expect the developers would agree to improve sys/soundcard.h, in some cases it's next to impossible. Consider for example that on Linux this header is provided by the kernel, and: - their attitude towards OSS (which they consider deprecated in favour of ALSA) - their attitude towards user-space device driving on their platform (our recent discussion about MSI support in UIO comes to mind here). -- Robert Millan
Re: Sound translator
El 23/09/15 a les 23:56, Olaf Buddenhagen ha escrit: On Sat, Sep 19, 2015 at 10:52:01AM +0200, Robert Millan wrote: So if you wanted Sun audio, then yes it's a 1:1 wrapper. Otherwise you have to convert. That's a bummer. I was assuming that all BSDs -- and by extension, Rump -- use OSS... It's very simple really. For rumposs I made OSS->Sun translation transparent by integrating libossaudio directly into the source tree (note it had to be integrated anyway, because of the modifications I stated in my previous mail). You can do the same in a translator: - Get ossaudio.c from rumposs, which includes all the necessary adjustments (also just pushed GNU/Hurd fixes few minutes ago). - Link it into your translator executable. - Instead of forwarding ioctls to rump_sys_ioctl(), forward them to _oss_ioctl() which is provided by ossaudio.c. I find OSS more useful than Sun audio myself, so I hacked a modified version of libossaudio (a conversion library included with NetBSD). How does that work in NetBSD? They provide libossaudio and then modify every OSS application to use _oss_ioctl() and link with -lossaudio. -- Robert Millan
Re: USB Mass Storage with rump
El 24/09/15 a les 00:05, Olaf Buddenhagen ha escrit: Instead, you could run a Rump instance with USB mass storage only which uses libusb as backend rather than its own *HCI driver (but that requires some coding work as it's currently not implemented ;-)) Yeah, I guess that's the price to pay if we want a properly layered driver stack based on an originally monolithic implementation :-) As long as we don't need to jump through hoops to achieve that (and it gets upstream support), I'd say it's worth the effort... If someone implements a libusb backend for Rump, I think upstream will be more than happy to accept it. On my experience, Rump upstream is demanding in terms of code quality, but very friendly and always open to discuss things. -- Robert Millan
Re: misc/50166
El 21/09/15 a les 23:53, Antti Kantee ha escrit: On 21/09/15 20:37, Robert Millan wrote: The result is much smaller than I expected. In fact, other than make (because of the bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc issues are handled by nbtool_config.h. Please consider attached patch. Ok I committed a variant of it (I moved the rump kernel userspace bits into rumpuser_port.h). Please check if NetBSD HEAD now works for your use case. Well I'm glad to say I just tested, and current CVS HEAD builds correctly on GNU/Hurd now. I'm also happy to apply a patch where MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel userspace code, if you (or someone else) want to send one in another PR. I think that would be nice having, but unfortunately I lack the spare time at the moment. CCing bug-hurd in case someone is interested. Thanks! -- Robert Millan
Rump errno conversion
El 16/09/15 a les 22:57, Robert Millan ha escrit:
int fd = rump_sys_open("/dev/ugenhc", RUMP_O_RDWR);
if (fd == -1)
error(1, rump_errtrans_rump2host(errno), "rump_sys_open");
Instead of rump_errtrans_rump2host() this should be rump_errno2host() which
is the function name that was finally committed in upstream. Sorry for the
confusion.
--
Robert Millan
Re: USB Mass Storage with rump
El 19/09/15 a les 10:59, Samuel Thibault ha escrit: Instead, you could run a Rump instance with USB mass storage only which uses libusb as backend rather than its own *HCI driver (but that requires some coding work as it's currently not implemented ;-)) Indeed. We can however start with an all-in solution before adding multiplexing. If you want an all-in solution, a simple way to do this could be to run a single Rump instance inside a single translator which exposes all of /dev in Rump namespace somewhere under host /dev hierarchy (e.g. /dev/rump/*). Then it becomes very easy to select what you want, and no matter what you do it's always a single Rump instance. For example: - if you want your /dev/hd1 to be a Rump USB mass storage, a symlink will do. - if you want raw access to network cards, one could have a translator which opens /dev/rump/bpf (Berkeley Packet Filter) to capture and inject packets. - if you want OSS rather than Sun audio, maybe you'll want a translator which opens /dev/rump/audio and exports OSS in /dev/audio, /dev/dsp, etc. -- Robert Millan
Re: Sound translator / PCI device handling
[Adding rumpkernel-users] El 19/09/15 a les 01:21, Olaf Buddenhagen ha escrit: Is there no way to limit the probing to a particular device, though? In the long run, it really seems cleaner to tell the driver, "please try to serve this device", rather than "go out and see whether you can find any devices to your liking..." See the Linux version of rumpcomp_pci_map() in pci-userspace [1]. IIRC this is used by librumpdev_pci to enumerate available PCI devices. Or if not that function, certainly something in that file ;-) On Linux, this is ultimately determined by UIO module settings (admin tells Linux which devices are available to user-space code, see [2] for UIO setup instructions). When I implemented the GNU/Hurd backend, I observed there's no such thing as Linux' UIO restricting access to PCI devices, so I simply made it use libpciaccess for scanning and blindly accepting anything it finds (not the Linux backend doesn't use libpciaccess at all, it just uses UIO for equivalent functionality). So AFAIK there's no framework to manage which devices are available to Rump, but if one wanted to implement it pci-userspace/src-gnu/ seems the place to do it. [1] https://github.com/rumpkernel/pci-userspace [2] https://github.com/rumpkernel/wiki/wiki/Howto%3A-Accessing-PCI-devices-from-userspace -- Robert Millan
Re: Sound translator
El 19/09/15 a les 01:06, Olaf Buddenhagen ha escrit: This could work -- but I'm not sure it would be very useful? Is there any actual logic that could be split out into the audio and mixer translators? My suspicion is that they would rather just be straightforward wrappers -- in which case it seems an unnecessary complication... That depends on the sound API you want to provide to applications. Rump doesn't implement OSS, but rather "Sun audio", which seems to be an ancestor of OSS, with very similar design. So if you wanted Sun audio, then yes it's a 1:1 wrapper. Otherwise you have to convert. I find OSS more useful than Sun audio myself, so I hacked a modified version of libossaudio (a conversion library included with NetBSD). This required a few changes to: - Make libossaudio use Rump as backend, rather than /dev/audio from the host - Make it build with non-NetBSD version of . My changes were for the Linux version but when I checked on GNU/Hurd it just needed minor adjustments. - Use modified versions of to define Rump _IOC* macros without namespace collision with system-wide ioctls. See: https://github.com/robertmillan/rumposs -- Robert Millan
Re: USB Mass Storage with rump
El 19/09/15 a les 00:52, Olaf Buddenhagen ha escrit: On Wed, Sep 16, 2015 at 10:57:20PM +0200, Robert Millan wrote: El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit: I'm interested in USB support. I'd like to aim mass storage devices at first. For USB using Rump, I think most of the pieces exist already. Rump implements the ugenhc NetBSD API, which is already supported by libusb, so if you want to support all libusb-aware applications, I think you'd just need something like: (cups|sane|whatever) ---> libusb > /dev/rumpusb (in Hurd VFS) > your translator > librump > /dev/ugenhc This looks nice for generic USB. I doubt we have a mass storage driver using libusb though? Rather, I guess it's something rump implements internally, and would be exposed through a different entry point? Yes and no. If you load *HCI support and USB mass storage into Rump, you can have /dev/XXX pop up in the Rump namespace and that will be your disk node. Then you can write a translator to link the host system into that disk (or whatever way this is handled, does ext2fs open device nodes directly?). Note, however, unless the same Rump instance also exports raw USB access as described above, it will be the only possible user of USB in the system! Since you most likely want to provide multiplexing, authorisation, etc, to any application who wants to access USB, I wouldn't recommend to lump USB mass storage and *HCI in the same Rump instance. Instead, you could run a Rump instance with USB mass storage only which uses libusb as backend rather than its own *HCI driver (but that requires some coding work as it's currently not implemented ;-)) -- Robert Millan
Re: Full-time developer available
El 18/09/15 a les 01:15, Justus Winter ha escrit: Quoting Robert Millan (2015-09-15 22:11:15) like, how to service ioctls without libtrivfs? Is there a reason why you don't want to use libtrivfs? Not particularly. I just noticed that libtrivfs doesn't implement a stub for ioctls like it does for other file operations. But then Samuel's recent comments cast some light on that (I haven't looked in detail though). -- Robert Millan
Re: Full-time developer available
El 17/09/15 a les 23:25, Samuel Thibault ha escrit: Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit : As for the rest of PCI devices, AFAICT they're free to be used by whoever wants them. My understanding is there's no need for an arbiter / multiplexer as long as all the code playing with PCI devices is well-aware of its limits. Yes, for the daily work, the driver can behave well. But to know where the PCI registers are, you need to read that from the config. And that includes unsafe concurrent accesses (i.e. write to a register, read the value). See inside libpciaccess, x86_pci.c which does inl(); outl(); inl(); outl(); Ah, I see what you mean. This seems like a bug in libpciaccess... the routines aren't even thread-safe! It looks like a generic problem, affecting all uses of libpciaccess (on other OS too). I guess it's been tolerated so far because there isn't any readily available solution. CPUs don't know how to "atomic test and set" on I/O space and pthread_mutex_t only cares about other threads in the same process. This makes me think on MAP_SHARED mmap of some system-wide file e.g. /run/io.lock or such, then an "inter-process mutex" on top of that. Does this look sane? Would a giant lock for all I/O serve the needs of all inb/outb users? Would it be possible to solve this in a portable way? -- Robert Millan
Re: Full-time developer available
Hi Samuel, El 17/09/15 a les 17:35, Samuel Thibault ha escrit: For me, the idea could be that you run a rump translator per PCI device, That doesn't fit very well with the way Rump works. With Rump you select drivers rather than specific devices. So for example if you start a Rump instance and load the librumpdev_pci_auich driver, auich driver scans the PCI bus for ICH audio devices and registers them as /dev/audio* in the internal vfs namespace of this instance. As for the rest of PCI devices, AFAICT they're free to be used by whoever wants them. My understanding is there's no need for an arbiter / multiplexer as long as all the code playing with PCI devices is well-aware of its limits. We'd need a common PCI translator to multiplex accesses to the config space, Rump accesses the PCI config space using libpciaccess. Are there coherency issues with separate processes doing this concurrently? AFAIK it shouldn't be a problem because hardware-mapped memory is excluded from processor caches. -- Robert Millan
Re: Full-time developer available
El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
That said I think Rump opens up a lot of interesting possibilities.
I'm glad to see interest in that. Which particular area do you have
in mind?
I'm interested in USB support. I'd like to aim mass storage devices at
first.
For USB using Rump, I think most of the pieces exist already. Rump implements
the ugenhc NetBSD API, which is already supported by libusb, so if you want
to support all libusb-aware applications, I think you'd just need something
like:
(cups|sane|whatever) ---> libusb > /dev/rumpusb (in Hurd VFS) > your
translator > librump > /dev/ugenhc
Rump API is very straightforward. It's basically POSIX with a few translation
gimmicks. E.g.
int fd = rump_sys_open("/dev/ugenhc", RUMP_O_RDWR);
if (fd == -1)
error(1, rump_errtrans_rump2host(errno), "rump_sys_open");
I was planning to ask for advice on how to make a "/dev/audio ->
librump0" translator sometime soon. I've written similar a glue layer
for Linux [1], but I'm missing a lot of knowledge when it comes to
the Hurd way of doing this (like, how to service ioctls without
libtrivfs?).
I also need the same kind of advice. I think a discussion about this
subject will help both of us and also other people who are struggling to
get an in-depth understanding of Hurd's ways.
Yes. This (ioctl handling) was the main blocker when I attempted an audio
translator. Some advice would be very welcome.
The other problem I had is that I don't know how to make a single translator
service two separate device nodes (obviously you don't want to start a
different Rump instance for /dev/audio, /dev/mixer, etc as they would fight
each other trying to access the same hardware). At least for audio this is
a lesser problem though, as /dev/audio is useful as a standalone node.
BR & happy hacking
--
Robert Millan
Re: Full-time developer available
Hi Bruno, El 14/09/15 a les 00:32, Bruno Félix Rezende Ribeiro ha escrit: I'm interested in improving Hurd's hardware support, probably working on the development of user-space device drivers[0], most likely the rump kernel integration. I see that Robert Millan has made some remarkable progress in that area, and I'd like to help. As I don't like to take credit for someone else's work, I'd just like to point out the groundwork for user-space driver support was already there and my effort has been basically to put the pieces together in a different way. I think it's mostly Zheng Da's merit. That said I think Rump opens up a lot of interesting possibilities. I'm glad to see interest in that. Which particular area do you have in mind? I was planning to ask for advice on how to make a "/dev/audio -> librump0" translator sometime soon. I've written similar a glue layer for Linux [1], but I'm missing a lot of knowledge when it comes to the Hurd way of doing this (like, how to service ioctls without libtrivfs?). Regards [1] https://github.com/robertmillan/rumposs -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
Hi Antti El 31/08/15 a les 21:05, Antti Kantee ha escrit: On 31/08/15 14:30, Robert Millan wrote: El 31/08/15 a les 16:04, Robert Millan ha escrit: I had some trouble with the .BEGIN approach, but the MAKEFILEINC one works perfectly. I'm attaching a patch. Actually, please use this one, which includes .ifdef not to break other platforms ;-) Yea I'll probably add something like that, but need to think about it a bit more first, namely why didn't I do that originally. Either I was being stupid, or there was some actual reason. I'll let you know. Use the .BEGIN way for now if you can make it work (or drag the local patch for a few days). Hereby, a kind reminder :) -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
El 31/08/15 a les 16:04, Robert Millan ha escrit:
I had some trouble with the .BEGIN approach, but the MAKEFILEINC one works
perfectly. I'm attaching a patch.
Actually, please use this one, which includes .ifdef not to break other
platforms ;-)
--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
===
--- rumpkernel-0~20150715.orig/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile 2015-08-15 12:10:33.0 +0200
+++ rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile 2015-08-31 16:19:58.220017146 +0200
@@ -41,6 +41,10 @@
# XXX: messy
.undef RUMPKERN_ONLY
+.ifdef RUMPCOMP_MAKEFILEINC.rumpdev_pci
+.include "${RUMPCOMP_MAKEFILEINC.rumpdev_pci}"
+.endif
+
.include "${RUMPTOP}/Makefile.rump"
.include
.include
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
El 31/08/15 a les 13:07, Antti Kantee ha escrit:
On 30/08/15 15:10, Robert Millan wrote:
But that's not what you were asking for. I don't know what's wrong
based on the above. Can you paste the entire Makefile and command line?
Makefile is attached (in my tree, this is pci-userspace/src-gnu/Makefile)
Command-line is:
../../buildrump.sh/obj/tooldir/rumpmake dependall
Ah. That happens because the make which needs experimentalUser.c does not see
the rule in the current Makefile (everything in SUBDIR is run in another make).
The easy way to fix it is to add the following line to the Makefile containing
the rule and SUBDIRs:
.BEGIN: experimentalUser.c
It's a slightly weird way to use make, though.
I wonder if rump/dev/lib/libpci should look at a variable to decide if it needs to
include some further definitions, e.g. RUMPCOMP_MAKEFILEINC.compname. That would solve
both LDFLAGS and this issue. "leave it to the client"
I had some trouble with the .BEGIN approach, but the MAKEFILEINC one works
perfectly. I'm attaching a patch.
--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
===
--- rumpkernel-0~20150715.orig/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
+++ rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
@@ -41,6 +41,8 @@ CPPFLAGS+= ${RUMPCOMP_CPPFLAGS.rumpdev_
# XXX: messy
.undef RUMPKERN_ONLY
+.include "${RUMPCOMP_MAKEFILEINC.rumpdev_pci}"
+
.include "${RUMPTOP}/Makefile.rump"
.include
.include
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
Hi Antti
El 30/08/15 a les 16:44, Antti Kantee ha escrit:
One thing you are doing wrong is creating a rule which creates two targets. If
both
> targets happen to be made in parallel, you usually get corrupt output. So
e.g. make
> the .h depend on the .c (or simply omit it entirely if nothing on the chain
depends on the .h).
Just omitted it then, thanks.
Might also consider replacing gcc with ${CC}?
Sure.
But that's not what you were asking for. I don't know what's wrong based on
the above. Can you paste the entire Makefile and command line?
Makefile is attached (in my tree, this is pci-userspace/src-gnu/Makefile)
Command-line is:
../../buildrump.sh/obj/tooldir/rumpmake dependall
Many thanks
--
Robert Millan
RUMPTOP= ${TOPRUMP}
RUMPCOMP_USER_SRCS.rumpdev_pci= pci_user-gnu.c experimentalUser.c
RUMPCOMP_USER_PATH.rumpdev_pci:=${.PARSEDIR}
RUMPCOMP_USER_CPPFLAGS.rumpdev_pci:=-I${.PARSEDIR}
RUMPCOMP_CPPFLAGS.rumpdev_pci:= -I${.PARSEDIR}
experimentalUser.c:
echo '#include ' \
| ${CC} -E -x c - -o - \
| mig -cc cat - /dev/null -subrprefix __ \
-user experimentalUser.c \
-server /dev/null \
-header experimental_U.h
.export RUMPCOMP_USER_SRCS.rumpdev_pci
.export RUMPCOMP_USER_PATH.rumpdev_pci
.export RUMPCOMP_USER_CPPFLAGS.rumpdev_pci
.export RUMPCOMP_CPPFLAGS.rumpdev_pci
.include "${RUMPTOP}/dev/Makefile.rumpdevcomp"
.for pcidev in ${RUMPPCIDEVS}
SUBDIR+= ${RUMPTOP}/dev/lib/lib${pcidev}
.endfor
.include
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
El 16/08/15 a les 13:09, Robert Millan ha escrit: * It includes code from other people under GPLv2; I'm not sure if this may be an issue wrt licensing policy of Rump as this is only targetted at the pci-userspace module. In any case if you think it's an issue let me know and we'll try to find a solution: ... - experimentalUser.c is an automatically generated file copied from the Hurd build tree. I would welcome some help from MIG experts on how to do this in a more elegant way. I figured out how to generate those off-tree and wrote a small Makefile snippet to do it: experimentalUser.c experimental_U.h: echo '#include ' \ | gcc -E -x c - -o - \ | mig -cc cat - /dev/null -subrprefix __ \ -user experimentalUser.c \ -server /dev/null \ -header experimental_U.h However no matter how I try to tell rumpmake the experimentalUser.c build instructions, it seems uncapable of doing so: nbmake[1]: don't know how to make experimentalUser.c. Stop I've tried using absolute paths to rule out that it's a cwd problem, but still same error. Any idea what I'm doing wrong? -- Robert Millan
Re: netdde drivers
Hi Samuel El 29/08/15 a les 00:17, Samuel Thibault ha escrit: Hello, As it seems we'll never synchronize netdde with DDE but rather go with Rump, That's an interesting proposition. Is someone working on a Rump-based network translator? FYI, I'm currently trying to get the remaining parts of my Rump port merged. Other than that, let me know if I can be of any help. -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (3): system limits
El 24/08/15 a les 23:45, Antti Kantee ha escrit: On 24/08/15 21:24, Robert Millan wrote: El 16/08/15 a les 15:07, Antti Kantee ha escrit: Can you submit the patches against NetBSD tools directly to NetBSD? [snip] Here: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50166 The buildrump.sh bit, again, please submit as a pull req on github. and here: https://github.com/rumpkernel/buildrump.sh/pull/73 Thanks. Merged the github ones, let's wait for a day or two on the NetBSD tools one before proceeding. Cool, thanks. If I'm not mistaken, after handling this (and errno translation) all of your patches will be accounted for. If I am mistaken, please correct me. I think not. But don't worry, I keep track of things. I'm slow but careful ;-) -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (3): system limits
El 16/08/15 a les 15:07, Antti Kantee ha escrit: Can you submit the patches against NetBSD tools directly to NetBSD? It's hard to test that one didn't break any platform when mucking around with the crosstools, so it never hurts to have the maximal amount of eyeballs on changes there. Specifically, I'm not sure what the fallout from AC_CANONICAL_HOST() will be (if any). If nobody else has comments or handles the PR, I can commit your patches in a few days. https://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd Here: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50166 The buildrump.sh bit, again, please submit as a pull req on github. and here: https://github.com/rumpkernel/buildrump.sh/pull/73 Thanks -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (1): system detection
El 16/08/15 a les 13:38, Antti Kantee ha escrit: On 16/08/15 10:48, Robert Millan wrote: Hi, Here's the first patch of my port of Rump to GNU/Hurd. It includes the basic system detection stuff. Applied the src-netbsd bits. Can you submit the buildrump.sh part as a pull req on github? Done! https://github.com/rumpkernel/buildrump.sh/pull/72 -- Robert Millan
Re: Sound on GNU/Hurd
El 17/08/15 a les 01:10, Arne Babenhauserheide ha escrit: Am Sonntag, 16. August 2015, 23:49:15 schrieb Robert Millan: I managed to play some sound on GNU/Hurd using patched Rump and a modified mplayer. For those interested: Cool! Thank you for sharing it! You're welcome :) Did you already share the patches in a public list? If not, could you send them here inline? Yes. I've sent them to rumpkernel-users and they're in the process of being merged (I still need to work some things out): https://www.freelists.org/archive/rumpkernel-users/ However if you just want a copy of the patched tree to build it from source and/or modify it, buildable Debian packages are in the APT repository I sent earlier. -- Robert Millan
Sound on GNU/Hurd
Hi, I managed to play some sound on GNU/Hurd using patched Rump and a modified mplayer. For those interested: 1. Setup APT repository (https://people.debian.org/~rmh/rump/apt/00README) 2. If using kvm, add "-soundhw ac97". With real hardware ICH/AC97 and Intel HD audio are supported. 3. Install mplayer from the repository and run with: mplayer -ao sun soundfile.ogg Enjoy :-) -- Robert Millan
Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
Hi Zheng Da, First of all, allow me to show you my appreciation for your effort on integrating DDE with the Hurd. The groundwork on creating facilities that enable userspace drivers has been greatly helpful on this little project of mine. Just to put you in context, I've ported Rump (http://rumpkernel.org/) to GNU/Hurd and written some extensions that allow it to run its own PCI drivers in userspace. For that I used the same facilities in Gnu Mach that libddekit is using, and also imported some the code in libddekit for userspace interrupt management. Olaf (see below) believes that this code was written by you: El 16/08/15 a les 21:02, Olaf Buddenhagen ha escrit: On Sun, Aug 16, 2015 at 01:09:59PM +0200, Robert Millan wrote: * It includes code from other people under GPLv2; - intrthread() is heavily based on intloop() from hurd/libddekit/interrupt.c I haven't checked, but I assume this is form a Hurd-specific part of DDE, which has been implemented by Zheng Da for the Hurd port specifically? If so, we could try contacting him. Is this correct? I'm currently trying to merge the resulting code into Rump. This raises the question on which license is the code in intloop() under. By lack of any other statement one would have to assume it's GPLv2. The Rump maintainer has some concern regarding licenses: El 16/08/15 a les 15:14, Antti Kantee ha escrit: >> * It includes code from other people under GPLv2; I'm not sure if this may be an issue wrt licensing >>policy of Rump as this is only targetted at the pci-userspace module. In any case if you >>think it's an issue let me know and we'll try to find a solution: >>- intrthread() is heavily based on intloop() from hurd/libddekit/interrupt.c >>[...] > > I'm not worried about GPL, but I am worried about someone using GPL accidentally when they did not intend to. It's better if the code can offered under LGLP, but not a requirement. One option would be to put Hurd support under "gpl/src-hurd". Or just be very explicit about the licensing both in LICENSE and README. So, to summarize, I'm writing this mail to find out about the authorship (can you confirm it's yours?), and in case this is your code to see where you stand regarding Antti's concerns. I.e. what's the current license terms; are you ok with relicensing; etc. Please let us know about it! Much appreciated, -- Robert Millan
gnumach-dev: please include intr.h
Package: gnumach-dev
Severity: wishlist
(followup from the Userspace PCI I/O discussion in bug-hurd / rumpkernel-users)
El 16/08/15 a les 15:14, Antti Kantee ha escrit:
- intr.h was just copied from GNU Mach source tree (I don't think it is
copyright-significant
though).
I traced this file to 70_dde.patch, which was added in 2012 to the Debian
package,
but not to upstream gnumach tree:
* debian/patches/70_dde.patch: Add experimental support for irq passing and
physical memory allocation for DDE. Also adds nonetdev boot parameter to
disable network device drivers.
hurd code (in Debian) basically duplicates it in libddekit/interrupt.c, e.g.:
libddekit/interrupt.c-#define MACH_INTR_NOTIFY 424242
libddekit/interrupt.c-
libddekit/interrupt.c-typedef struct
libddekit/interrupt.c-{
libddekit/interrupt.c- mach_msg_header_t intr_header;
libddekit/interrupt.c- mach_msg_type_t intr_type;
libddekit/interrupt.c- int line;
libddekit/interrupt.c:} mach_intr_notification_t;
Would you consider installing it in /usr/include/device/ for the sake of other
programs who also want to do funny things with interrupts on userspace? :-)
--
Robert Millan
licensing of intloop() from hurd/libddekit/interrupt.c
El 16/08/15 a les 15:14, Antti Kantee ha escrit: * It includes code from other people under GPLv2; I'm not sure if this may be an issue wrt licensing policy of Rump as this is only targetted at the pci-userspace module. In any case if you think it's an issue let me know and we'll try to find a solution: - intrthread() is heavily based on intloop() from hurd/libddekit/interrupt.c ... I'm not worried about GPL, but I am worried about someone using GPL accidentally when they did not intend to. It's better if the code can offered under LGLP, but not a requirement. One option would be to put Hurd support under "gpl/src-hurd". Or just be very explicit about the licensing both in LICENSE and README. Hi Samuel, According to the changelog you added this code to the Debian package in 2012. The header in interrupt.c lists two people from University of Dresden. Given the DDE heritage of the code, I'm not sure who's the author of intloop() routine, as it is mostly Gnumach-aware code and seems unlikely to be part of DDE per se. Do you recall where it came from? Many thanks -- Robert Millan
[PATCH] Rump on GNU/Hurd (3): system limits
Hi,
GNU/Hurd doesn't have PATH_MAX or MAXHOSTNAMELEN (arbitrarily long strings can
be used). Since attempting to replace every instance of static allocation with
dynamic buffer management would make for a very intrusive patch, I'm proposing
to just define the limits as alternative.
I took care to use the same limits Rump namespace has, just to avoid accidental
cross-definition of a different value causing damage somewhere (e.g. overflows
or such).
--
Robert Millan
--- a/buildrump.sh/buildrump.sh
+++ b/buildrump.sh/buildrump.sh
@@ -1074,6 +1074,7 @@
*-gnu*)
EXTRA_RUMPCOMMON='-ldl'
EXTRA_RUMPCLIENT='-lpthread'
+ appendvar EXTRA_CFLAGS -DMAXHOSTNAMELEN=256 -DPATH_MAX=1024
;;
*-openbsd*)
EXTRA_RUMPCLIENT='-lpthread'
--- a/buildrump.sh/src/tools/compat/Makefile
+++ b/buildrump.sh/src/tools/compat/Makefile
@@ -38,6 +38,11 @@
CPPFLAGS+= -I. -I./include -I${.CURDIR} -I${.CURDIR}/sys \
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
+# Define MAXPATHLEN limit on GNU/Hurd
+.if ${BUILD_OSTYPE} == "GNU"
+CPPFLAGS+= -DMAXPATHLEN=1024 -DPATH_MAX=1024
+.endif
+
.PATH: ${.CURDIR}/../../lib/libc/cdb \
${.CURDIR}/../../lib/libc/gen \
${.CURDIR}/../../lib/libc/hash \
--- a/buildrump.sh/src/tools/compat/defs.mk.in
+++ b/buildrump.sh/src/tools/compat/defs.mk.in
@@ -79,6 +79,11 @@
HOST_CPPFLAGS+= ${COMPATINCFLAGS} -I${NETBSDSRCDIR}/tools/compat \
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
+# Define MAXPATHLEN limit on GNU/Hurd
+.if ${BUILD_OSTYPE} == "GNU"
+HOST_CPPFLAGS+= -DMAXPATHLEN=1024 -DPATH_MAX=1024
+.endif
+
.if "${COMPATLIB_NO_LIB}" != "yes"
DPADD+= ${COMPATLIBDIR}/libnbcompat.a
LDADD+= -L${COMPATLIBDIR} -lnbcompat @LIBS@
--- a/buildrump.sh/src/tools/make/configure
+++ b/buildrump.sh/src/tools/make/configure
@@ -971,6 +971,10 @@
#define DEFSHELL_CUSTOM "${BSHELL}"
EOF
+cat >>confdefs.h <
[PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O
Hi,
This patch adds GNU/Hurd support to pci-userspace. Some notes:
* It uses libpciaccess to query/modify the PCI config stuff. This part of the
code is pretty
generic, perhaps this approach can be useful to other ports?
* It relies on the patch I sent yesterday (allow setting LDFLAGS from
pci-userspace Makefile)
to setup libpciaccess dependency
* It uses experimental GNU Mach interfaces that were added for DDE:
- vm_allocate_contiguous() to allocate contigously physical memory
- device_intr_register() / device_intr_enable() to synchronize with interrupts
* It includes code from other people under GPLv2; I'm not sure if this may be
an issue wrt licensing
policy of Rump as this is only targetted at the pci-userspace module. In any
case if you
think it's an issue let me know and we'll try to find a solution:
- intrthread() is heavily based on intloop() from hurd/libddekit/interrupt.c
- experimentalUser.c is an automatically generated file copied from the Hurd
build tree. I
would welcome some help from MIG experts on how to do this in a more
elegant way.
- intr.h was just copied from GNU Mach source tree (I don't think it is
copyright-significant
though).
--
Robert Millan
--- /dev/null
+++ b/pci-userspace/src-gnu/Makefile
@@ -0,0 +1,21 @@
+RUMPTOP= ${TOPRUMP}
+
+RUMPCOMP_USER_SRCS.rumpdev_pci= pci_user-gnu.c experimentalUser.c
+RUMPCOMP_USER_PATH.rumpdev_pci:= ${.PARSEDIR}
+RUMPCOMP_USER_CPPFLAGS.rumpdev_pci:= -I${.PARSEDIR}
+RUMPCOMP_CPPFLAGS.rumpdev_pci:= -I${.PARSEDIR}
+RUMPCOMP_LDFLAGS.rumpdev_pci:= -lpciaccess
+
+.export RUMPCOMP_USER_SRCS.rumpdev_pci
+.export RUMPCOMP_USER_PATH.rumpdev_pci
+.export RUMPCOMP_USER_CPPFLAGS.rumpdev_pci
+.export RUMPCOMP_CPPFLAGS.rumpdev_pci
+.export RUMPCOMP_LDFLAGS.rumpdev_pci
+
+.include "${RUMPTOP}/dev/Makefile.rumpdevcomp"
+
+.for pcidev in ${RUMPPCIDEVS}
+SUBDIR+= ${RUMPTOP}/dev/lib/lib${pcidev}
+.endfor
+
+.include
--- /dev/null
+++ b/pci-userspace/src-gnu/experimentalUser.c
@@ -0,0 +1,461 @@
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
+#include "experimental_U.h"
+#define EXPORT_BOOLEAN
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifndef mig_internal
+#define mig_internal static
+#endif
+
+#ifndef mig_external
+#define mig_external
+#endif
+
+#ifndef mig_unlikely
+#define mig_unlikely(X) __builtin_expect (!! (X), 0)
+#endif
+
+#ifndef TypeCheck
+#define TypeCheck 1
+#endif
+
+#ifndef UseExternRCSId
+#define UseExternRCSId 1
+#endif
+
+#define BAD_TYPECHECK(type, check) mig_unlikely (({\
+ union { mach_msg_type_t t; unsigned32_t w; } _t, _c;\
+ _t.t = *(type); _c.t = *(check);_t.w != _c.w; }))
+#define msgh_request_port msgh_remote_port
+#define msgh_reply_port msgh_local_port
+
+#include
+#include
+
+/* Routine device_intr_register */
+mig_external kern_return_t device_intr_register
+(
+ mach_port_t master_port,
+ int line,
+ int id,
+ int flags,
+ mach_port_t receive_port,
+ mach_msg_type_name_t receive_portPoly
+)
+{
+ typedef struct {
+ mach_msg_header_t Head;
+ mach_msg_type_t lineType;
+ int line;
+ mach_msg_type_t idType;
+ int id;
+ mach_msg_type_t flagsType;
+ int flags;
+ mach_msg_type_t receive_portType;
+ mach_port_t receive_port;
+ } Request;
+
+ typedef struct {
+ mach_msg_header_t Head;
+ mach_msg_type_t RetCodeType;
+ kern_return_t RetCode;
+ } Reply;
+
+ union {
+ Request In;
+ Reply Out;
+ } Mess;
+
+ Request *InP = &Mess.In;
+ Reply *OutP = &Mess.Out;
+
+ mach_msg_return_t msg_result;
+ boolean_t msgh_simple = TRUE;
+
+ const mach_msg_type_t lineType = {
+ /* msgt_name = */ 2,
+ /* msgt_size = */ 32,
+ /* msgt_number = */ 1,
+ /* msgt_inline = */ TRUE,
+ /* msgt_longform = */ FALSE,
+ /* msgt_deallocate = */ FALSE,
+ /* msgt_unused = */ 0
+ };
+
+ const mach_msg_type_t idType = {
+ /* msgt_name = */ 2,
+ /* msgt_size = */ 32,
+ /* msgt_number = */ 1,
+ /* msgt_inline = */ TRUE,
+ /* msgt_longform = */ FALSE,
+ /* msgt_deallocate = */ FALSE,
+ /* msgt_unused = */ 0
+ };
+
+ const mach_msg_type_t flagsType = {
+ /* msgt_name = */ 2,
+ /* msgt_size = */ 32,
+ /* msgt_number = */ 1,
+ /* msgt_inline = */ TRUE,
+ /* msgt_longform = */ FALSE,
+ /* msgt_deallocate = */ FALSE,
+ /* msgt_unused = */ 0
+ };
+
+ const mach_msg_type_t receive_portType = {
+ /* msgt_name = */ -1,
+ /* msgt_size = */ 32,
+ /* msgt_number = */ 1,
+ /* msgt_inline = */ TRUE,
+ /* msgt_longform = */ FALSE,
+ /* msgt_deallocate = */ FALSE,
+ /* msgt_unused = */ 0
+ };
+
+ const mach_msg_type_t RetCodeCheck = {
+ /* msgt_name = */ MACH_MSG_TYPE_INTEGER_32,
+ /* msgt_size = */ 32,
+ /* msgt_number = */ 1,
+ /* msgt_inline = */ TRUE,
+ /* msgt_longform = */ FALSE,
+ /* msgt_deallocate = */ FALSE,
+ /* msgt_unused = */ 0
+ };
+
+ InP->lineType = lineType;
+
+ InP->line = line;
+
+ InP->idType = idType;
+
+ InP->id = id;
+
+
[PATCH] Rump on GNU/Hurd (1): system detection
Hi, Here's the first patch of my port of Rump to GNU/Hurd. It includes the basic system detection stuff. -- Robert Millan --- a/buildrump.sh/buildrump.sh +++ b/buildrump.sh/buildrump.sh @@ -993,6 +993,13 @@ cppdefines _LITTLE_ENDIAN \ && appendvar RUMPKERN_UNDEF -U_LITTLE_ENDIAN ;; + *-gnu*) + RUMPKERN_UNDEF='-U__GNU__' + cppdefines _BIG_ENDIAN \ + && appendvar RUMPKERN_UNDEF -U_BIG_ENDIAN + cppdefines _LITTLE_ENDIAN \ + && appendvar RUMPKERN_UNDEF -U_LITTLE_ENDIAN + ;; *-dragonflybsd) RUMPKERN_UNDEF='-U__DragonFly__' ;; @@ -1064,6 +1071,10 @@ doesitbuild '#include ' -c && RUMP_VIRTIF=yes cppdefines '__ANDROID__' || HIJACK=true ;; + *-gnu*) + EXTRA_RUMPCOMMON='-ldl' + EXTRA_RUMPCLIENT='-lpthread' + ;; *-openbsd*) EXTRA_RUMPCLIENT='-lpthread' ;; --- a/buildrump.sh/src/lib/librumpuser/rumpuser_port.h +++ b/buildrump.sh/src/lib/librumpuser/rumpuser_port.h @@ -63,7 +63,7 @@ #include "rumpuser_config.h" #endif -#ifdef __linux__ +#if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__) #define _GNU_SOURCE #endif --- a/buildrump.sh/src/lib/librumpuser/rumpuser_sp.c +++ b/buildrump.sh/src/lib/librumpuser/rumpuser_sp.c @@ -90,7 +90,7 @@ /* how to use atomic ops on Linux? */ -#if defined(__linux__) || defined(__APPLE__) || defined(__CYGWIN__) || defined(__OpenBSD__) +#if defined(__linux__) || defined(__APPLE__) || defined(__CYGWIN__) || defined(__OpenBSD__) || defined(__GNU__) || defined(__GLIBC__) static pthread_mutex_t discomtx = PTHREAD_MUTEX_INITIALIZER; static void
[PATCH] Rump on GNU/Hurd (2): missing
Hi, Apparently this routine only wants the Rump version of when building with Rump namespace, but it includes the header unconditionally. This is usually harmless as almost everyone has , but GNU/Hurd doesn't. So my patch just moves it into Rump protected space. -- Robert Millan --- a/buildrump.sh/src/sys/sys/syscallargs.h +++ b/buildrump.sh/src/sys/sys/syscallargs.h @@ -10,8 +10,8 @@ #ifndef _SYS_SYSCALLARGS_H_ #define _SYS_SYSCALLARGS_H_ -#include #ifndef RUMP_CLIENT +#include #include #endif #include
Bug#263748: Split fakeroot into a separate package.
On Thu, Aug 05, 2004 at 10:14:19PM +0300, Ognyan Kulev wrote: > Robert Millan wrote: > >We're eventualy going to port fakeroot. So if we want it installable on > >GNU, > >the [/usr]/bin/fakeroot the Hurd package provides should be split in a > >separate package (e.g. hurd-fakeroot) that conflicts and provides fakeroot. > > dpkg-divert? Or it's not suited for this kind of stuff? This should be dealt with the fakeroot maintainer, then. But I don't think it's the more suitable solution. I.e.: fakeroot is currently in an Essential package, and it's not true that you need this binary for a minimal system to work. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution)) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Bug#263748: Split fakeroot into a separate package.
Package: hurd Version: 20040508-2 Severity: wishlist Hi! We're eventualy going to port fakeroot. So if we want it installable on GNU, the [/usr]/bin/fakeroot the Hurd package provides should be split in a separate package (e.g. hurd-fakeroot) that conflicts and provides fakeroot. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-i386 (i386) Kernel: GNU/kFreeBSD 5.2.1-5 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Bug#196913: please redo the patch
tags 196913 - patch submitter 196913 [EMAIL PROTECTED] thanks Hi! This patch does no longer apply to the debian hurd package, since the rules file has been rewritten. Ogi, please have a look. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Bug#252323: More binary-only software
There's also fpe.b and fpe.b_elf. See the discussion in upstream: http://lists.gnu.org/archive/html/bug-hurd/2004-03/msg00223.html -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Bug#252323: Contains binary-only firmware (from Linux)
Package: gnumach Severity: serious Non-surprisingly, since gnumach borrowed drivers from linux it also borrowed binary-only firmware, which is non-free under DFSG. At least the following files are affected: linux/src/drivers/scsi/qlogicisp_asm.c I inspected the whole "linux" directory in gnumach and couldn't find more of these, but don't take my word for it as it was a quick look. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to C) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Bug#246813: /usr/sbin/update-rc.d conflicts with sysv-rc's
Package: hurd Severity: serious The hurd package is providing /usr/sbin/update-rc.d, that conflicts with the file provided in sysv-rc. You either need a Replaces or removing that file from the hurd package. I recommend the latter, since the standard update-rc.d in debian is more likely to cope with debian's semantics. This problem breaks installation from crosshurd. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7 Locale: LANG=C, LC_CTYPE=C ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
bits/in.h portability: Patch and RFC
-/* IPV6 socket options. */
+/* As above but including interface specification by index. */
+struct ip_mreqn
+ {
+struct in_addr imr_multiaddr; /* IP multicast address of group */
+struct in_addr imr_address;/* local IP address of interface */
+intimr_ifindex;/* Interface index */
+ };
+
+/* Structure used for IP_PKTINFO. */
+struct in_pktinfo
+ {
+int ipi_ifindex; /* Interface index */
+struct in_addr ipi_spec_dst; /* Routing destination address */
+struct in_addr ipi_addr; /* Header destination address */
+ };
+
+/* Options for use with `getsockopt' and `setsockopt' at the IPv6 level.
+ The first word in the comment at the right is the data type used;
+ "bool" means a boolean value stored in an `int'. */
#define IPV6_ADDRFORM 1
-#define IPV6_RXINFO2
+#define IPV6_PKTINFO 2
#define IPV6_HOPOPTS 3
#define IPV6_DSTOPTS 4
#define IPV6_RTHDR 5
@@ -71,16 +105,25 @@
#define IPV6_CHECKSUM 7
#define IPV6_HOPLIMIT 8
-#define IPV6_TXINFOIPV6_RXINFO
-#define SCM_SRCINFOIPV6_TXINFO
#define SCM_SRCRT IPV6_RXSRCRT
+#define IPV6_NEXTHOP 9
+#define IPV6_AUTHHDR 10
#define IPV6_UNICAST_HOPS 16
#define IPV6_MULTICAST_IF 17
#define IPV6_MULTICAST_HOPS18
#define IPV6_MULTICAST_LOOP19
#define IPV6_JOIN_GROUP20
#define IPV6_LEAVE_GROUP 21
+#define IPV6_ROUTER_ALERT 22
+#define IPV6_MTU_DISCOVER 23
+#define IPV6_MTU 24
+#define IPV6_RECVERR 25
+#define IPV6_V6ONLY26
+#define IPV6_JOIN_ANYCAST 27
+#define IPV6_LEAVE_ANYCAST 28
+#define IPV6_IPSEC_POLICY 34
+#define IPV6_XFRM_POLICY 35
/* Obsolete synonyms for the above. */
#define IPV6_ADD_MEMBERSHIPIPV6_JOIN_GROUP
@@ -88,6 +131,15 @@
#define IPV6_RXHOPOPTS IPV6_HOPOPTS
#define IPV6_RXDSTOPTS IPV6_DSTOPTS
+/* IPV6_MTU_DISCOVER values. */
+#define IPV6_PMTUDISC_DONT 0 /* Never send DF frames. */
+#define IPV6_PMTUDISC_WANT 1 /* Use per route hints. */
+#define IPV6_PMTUDISC_DO 2 /* Always DF. */
+
+/* Socket level values for IPv6. */
+#define SOL_IPV641
+#define SOL_ICMPV6 58
+
/* Routing header options for IPv6. */
#define IPV6_RTHDR_LOOSE 0 /* Hop doesn't need to be neighbour. */
#define IPV6_RTHDR_STRICT 1 /* Hop must be a neighbour. */
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T., Ainulindale (Silmarillion)
2004-04-10 Robert Millan <[EMAIL PROTECTED]>
* sysdeps/unix/sysv/linux/bits/in.h: Cosmetic fixes to get in sync
with sysdeps/generic/bits/in.h.
--- libc/sysdeps/unix/sysv/linux/bits/in.h.old 2004-04-10 17:54:51.0 +0200
+++ libc/sysdeps/unix/sysv/linux/bits/in.h 2004-04-10 17:55:08.0 +0200
@@ -25,13 +25,21 @@
/* Options for use with `getsockopt' and `setsockopt' at the IP level.
The first word in the comment at the right is the data type used;
"bool" means a boolean value stored in an `int'. */
-#define IP_TOS 1 /* int; IP type of service and precedence. */
-#define IP_TTL 2 /* int; IP time to live. */
-#define IP_HDRINCL 3 /* int; Header is included with data. */
-#define IP_OPTIONS 4 /* ip_opts; IP per-packet options. */
+#defineIP_OPTIONS 4 /* ip_opts; IP per-packet options. */
+#defineIP_HDRINCL 3 /* int; Header is included with data. */
+#defineIP_TOS 1 /* int; IP type of service and precedence. */
+#defineIP_TTL 2 /* int; IP time to live. */
+#defineIP_RECVOPTS 6 /* bool; Receive all IP options w/datagram. */
+/* For BSD compatibility. */
+#defineIP_RECVRETOPTS IP_RETOPTS /* bool; Receive IP options for
response. */
+#defineIP_RETOPTS 7 /* ip_opts; Set/get IP per-packet options. */
+#define IP_MULTICAST_IF 32 /* in_addr; set/get IP multicast i/f */
+#define IP_MULTICAST_TTL 33/* u_char; set/get IP multicast ttl */
+#define IP_MULTICAST_LOOP 34 /* i_char; set/get IP multicast loopback */
+#define IP_ADD_MEMBERSHIP 35 /* ip_mreq; add an IP group membership */
+#define IP_DROP_MEMBERSHIP 36 /* ip_mreq; drop an IP group membership */
+
#define IP_ROUTER_ALERT5 /* bool */
-#define IP_RECVOPTS6 /* bool */
-#define IP_RETOPTS 7 /* bool */
#define IP_PKTINFO 8 /* bool */
#define IP_PKTOPTIONS 9
#define
Bug#184624: reboots unexpectedly after panic
On Tue, Mar 02, 2004 at 04:48:40PM +0100, Alfred M. Szmidt wrote: >Perhaps I can even change GNU Mach so this becomes the default >behaviour and you can use an argument to switch to the old >behavior. > > Please don't. A option that makes GNU Mach halt is ok, the default > should be "quick reboot". > >Does someone think such patch would be useful? > > Yes. But only if the current behaviour is left as default. Why not sleep for, say, 10 seconds then reboot? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#184624: reboots unexpectedly after panic
On Tue, Mar 02, 2004 at 11:43:06AM +0100, M. Gerards wrote: > [...] > > I already have the "for (;;);" hack in my tree. Perhaps I can even change GNU > Mach so this becomes the default behaviour and you can use an argument to switch > to the old behavior. > > Does someone think such patch would be useful? I do (although I prefer while(1) ;) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#184624: reboots unexpectedly after panic
On Mon, Mar 01, 2004 at 02:53:43PM +0100, Michael Banck wrote:
> I was just reading the FAQ on http://www.gnu.org/software/hurd/faq.en.html
> and noticed this:
>
> --8<--
> 5.5. When GNU/Hurd crashes, GNU Mach automatically reboots. Is there
> anyway I can make it pause so I can write down the error?
>
> {MB} Pass the `-H' option to init (add it to the boot command line), and
> `init' will tell Mach to enter the kernel debugger instead to rebooting
> it. At the debugger prompt (`db>'), you can type `reboot' any time to
> reboot the system.
> --8<--
>
>
> Maybe that helps in your case?
I'm not working on GNU/Hurd currently, but I think the default behaviour
instead of reboot should either be halt or enter the debugger.
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T., Ainulindale (Silmarillion)
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [NEWS] "Thomas Bushnell Leaves HURD"
On Fri, Nov 21, 2003 at 04:27:59PM +0200, Ognyan Kulev wrote: > Robert Millan wrote: > >Just to say this is strictly an upstream issue about the Hurd itself, not > >GNU/Hurd distributions. So I think help-hurd would be more appropiate than > >debian-hurd for pointing this sort of things. > > IMO Debian is involved, because its attitude to GNU FDL is indirect > reason for this. (Obviously, Thomas Bushnell considers himself as part > of Debian.) Not that I judge if it is good or bad. Uhm.. as I said before I won't get into the "politics", but if that is the intended meaning, debian-project or debian-legal is probably a better target. It's not that I'm against this discussion, but debian-hurd doesn't seem like the appropiate place (we had tons of flames on this in -legal already) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [NEWS] "Thomas Bushnell Leaves HURD"
Hi Ognyan! On Fri, Nov 21, 2003 at 01:43:28PM +0200, Ognyan Kulev wrote: > /* Cross-post to bug-hurd and debian-hurd. */ I'm glad that I have no comments on the "politics" :) Just to say this is strictly an upstream issue about the Hurd itself, not GNU/Hurd distributions. So I think help-hurd would be more appropiate than debian-hurd for pointing this sort of things. > Hi, > > The Hurd is in the news, but for unpleasant event. In case you missed > it: http://www.osnews.com/comment.php?news_id=5185 -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: FTBFS: python
On Wed, Nov 19, 2003 at 11:56:06PM +0100, Santiago Vila wrote: > > Indeed. > > It's Debian who decided (implicitly, by not special-casing the Hurd) that > the Debian python package (for which I asked for help to compile) should be > compiled with threads support. > > Perhaps we should ask ourselves whether or not it might be worth to > ask the maintainer to disable threads completely for hurd-i386 until > we know how to fix this, since a python package without threads support > is obviously more useful than not having a python package at all. If using the libpthread implementation in the Hurd is a problem, we could easily enable libpthread emulation in libpth untill NPTL is ported to Mach, like I did for the GNU/KNetBSD port (see my last mail in bug #218011) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: FTBFS: python
On Mon, Nov 17, 2003 at 02:10:07PM +0100, Alfred M. Szmidt wrote: > [Moving this to bug-hurd since this has nothing todo with Debian] Ok but don't drop the CC, it's still a porting issue Debian is interested in. >> python: ../../libpthread/sysdeps/generic/pt-mutex-timedlock.c:55: > __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. > > Try running python under [gdb] and see what happens. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: GRUB patch for 'lilo -R' functionality
On Tue, Nov 11, 2003 at 06:44:21PM +, Keir Fraser wrote: > > I only changed the behaviour of savedefault when executed within the > GRUB-util shell (ie. not GRUB menu mode). I can't think of a scenario > where the '--once' semantics would be useful to access from the GRUB > menu, so I'm reluctant to 'fix' this behaviour. I think there's a missunderstanding here. savedefault itself is only meaningful in the context of the menu. The problem I noticed is that while "savedefault --default=X" affects the GRUB menu, the "--once" argument has no effect. I.e: once you run savedefault it won't be restored to 0 after the next GRUB run. > If the patch will make it to the main tree then I may investigate > fixing this issue --- I suspect it wouldn't be too hard. Okuji should pronounce on this, but I don't think the patch should be commited untill "--once" is fixed. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
GRUB patch for 'lilo -R' functionality
Hi! I gave a try to your patch for 'lilo -R' functionality in GRUB: http://mail.gnu.org/archive/html/bug-grub/2002-02/msg00151.html it seems to basicaly work, but the --once flag is not honored when running the real grub (I don't know if the problem is in savedefault or in the boot routine itself). Could you review that? If it works, I intend to apply it at least for the Debian package, and possibly for CVS too (if Okuji agrees). For GRUB CVS, though, there's the issue of copyright assignment. Have you assigned copyright for GRUB or been asked about this before? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: prealpha hush release
On Tue, Oct 28, 2003 at 01:30:57PM +0100, [EMAIL PROTECTED] wrote: > > FYI, > > i just released an extremely-alpha version of hush. What is hush? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Implementing ACL support (Was: EA/ACL interface documents)
Thanks Nathan, I'm forwarding this to bug-hurd just in case anyone is interested. On Thu, Oct 16, 2003 at 09:15:57AM +1000, Nathan Scott wrote: > > Robert, you might be able to find Andreas' message in a > "linux-fsdevel" mailing list archive somewhere on the net > (looking at maybe one/two years ago now?) > > > FreeBSD: http://www.trustedbsd.org/trustedbsd-bsdcon-2000.ps.gz (and > > http://www.trustedbsd.org/docs.html) > > > > Irix: There are several design studies as part of the OB1 documentation. > > I couldn't find the project web page anymore. > > There's also: > > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/attr.z&srch=extended%20attributes > > This is the attr(1) man page on IRIX, and has links to the 10 IRIX > extended attribute system calls' man pages in the SEE ALSO section. > > cheers. > > -- > Nathan -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Implementing ACL support (Was: EA/ACL interface documents)
Hi there, After getting libacl to compile on GNU/Hurd, i got stumbled on runtime problems [1]. It seems to be using kernel-specific interfaces that need to be implemented in Glibc/Hurd. Below is a mail from libacl upstream describing the implementation of EA/ACL interfaces on other operating systems. Just in case someone wants to hack on this.. [1] "Illegal instruction". Probably the result of attempting to access syscalls via interrupts. I didn't have GDB at hand to check, though. On Wed, Oct 15, 2003 at 12:25:58PM +0200, Andreas Gruenbacher wrote: > On Wed, 2003-10-15 at 04:05, Nathan Scott wrote: > > > > Hi Andreas, > > > > Do you still have that list of URLs pointing to various > > operating systems' implementations of EA/ACL interfaces? > > I seem to remember you posting this (ages ago) with some > > pointers to IRIX, Tru64, and one/two BSD interfaces. > > Oh my dear, that must have been ages ago. I don't find anything anymore > :-) The implementations themselves are described in the following > docs/papers: > > FreeBSD: http://www.trustedbsd.org/trustedbsd-bsdcon-2000.ps.gz (and > http://www.trustedbsd.org/docs.html) > > Irix: There are several design studies as part of the OB1 documentation. > I couldn't find the project web page anymore. > > Linux: Probably the Freenix'03 paper is best, > http://www.suse.de/~agruen/acl/linux-acls/. The code itself also > contains some documentation (simply check out the kernel patches). > > Solaris: They have something like MacOS, each "extended attribute" there > is a separate file. No reference. > > > Cheers, > -- > Andreas Gruenbacher <[EMAIL PROTECTED]> > SuSE Labs, SuSE Linux AG <http://www.suse.de/> > -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 06:29:50PM -0400, Roland McGrath wrote: > > Are you willing to do reasonable discussion, or is this just going to be a > > claim without justification? > > I'm giving you a very accurate prediction, and being lazy about explaining > the responses I know you will get if you ask for it. Feel free to > experience it for yourself if you don't want to take my word for it. If > you propose it to libc and linux developers, you will get explanations > aplenty. I'd be happy to discuss ways that might actually fly to address > the problem that motivated your idea. I can count you as a libc developer, but this issue actualy seems to belong to Linux developers, so I'll deal with them and get their explanation. > Like I said, it would be perfectly reasonable on debian-hurd or other > debian lists to discuss ways to prevent packages from being built without > being fixed or annotated properly. This doesn't belong on bug-hurd, which > is about systems where no header file exists. Ok. I understand this is off-topic and leave it here. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 06:10:21PM -0400, Roland McGrath wrote: > Such header changes are just never going to happen, for many reasons. But > accept it. Are you willing to do reasonable discussion, or is this just going to be a claim without justification? > The way to move forward is to look for other solutions to help > people avoid writing needless implementation dependencies into their > packages. One straightforward idea is a tool to examine the header use in > source code or as part of a build, and flag nonportable header file names. That takes sorting out legitimate uses from illegitimate ones, and the whole cicle of sending patches so that they sit there eternaly and pinging them untill someone bothers to apply. I'm involved in boring porting tasks that you're not. And I'm so tired to go through the same crap over and over just because we allow programmers to do really insane things they should never do. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:54:43PM +0200, Jeroen Dekkers wrote: > > > > IIRC, Glibc build process takes them from specified location and installs them > > in /usr/include/linux/. > > > > So there's room to apply some patches. > > No they don't. Some distribution put those headers in a package called > glibc, but glibc itself doesn't do anything with them (except using it > in the glibc code itself of course). Linux headers are generaly found in /usr/src/linux, not /usr/include/linux. The only reason to install them in /usr/include hierrachy is so they can be used by Glibc. Too bad some people abuse that. In Debian, /usr/include/linux is provided by Glibc. Who provides these headers on other distributions? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sun, Oct 05, 2003 at 12:21:14AM +0200, Marco Gerards wrote: > > Correct me if I am wrong, but isn't debian-hurd for porting issues? debian-hurd is for debian issues, but maybe I was wrong at posting here and it should be in bug-hurd (too late to change that now, though). > I just don't understand what glibc has to do with improving the way > people code, especially when dealing with linux header files. Actualy Roland just pointed that the non-Debian world doesn't necessarily put Linux headers in Glibc package, so actualy this should be discussed in Linux mailing lists. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:50:20PM +0200, Jeroen Dekkers wrote: > > This is just too much of a burden for little gain. Everybody who uses > headers in general applications doesn't know what he is > doing. They will just #define USE_LINUX or whatever to get rid of the > warning/error. The real solution here is teaching people to do the > right thing, not putting silly things in glibc which don't solve the > problem at all. Not if the error message is good an explanative. For example, it could point to a README in /usr/include/linux/README that explains why including Linux headers is generaly a bad idea, and why the USE_LINUX macro should not be used unless we really need to access kernel interfaces. There's a difference between people who don't know what they are doing, and people who are plainly dumbass idiots. If you tell them what's correct to do, most of them will learn what's correct to do. Anyway, the people fixing build errors after appliing this change are not likely the same that those who introduced the insanity in first place, so there's little chance that they arbitrarily define USE_LINUX. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:58:20PM +0200, Marcus Brinkmann wrote: > On Sat, Oct 04, 2003 at 07:45:16PM +0000, Robert Millan wrote: > > I'll raise the issue on Glibc mailing lists, and CC bug-hurd. Please make > > sure you people get to participate. > > Why CC bug-hurd? This has nothing at all to do with the Hurd. It doesn't > affect us at all what the linux headers contain, so please don't give a > wrong impression. I believe you're not looking at it from the perspective of a porter who has to fix hundreds of broken packages which include . Please do that and my point will be made obvious. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:43:01PM +0200, Farid Hajji wrote: > > > I think we should disallow direct inclusion of in Glibc, any > > > comments? > > There don't exist any headers in glibc, they come from > > Linux. > > Perhaps glibc should provide its own wrappers which > would spew out warnings, but still #include the real linux headers > (I assume something from /usr/src/linux/include/*.h or whatever) > anyway? Good idea, I'll propose that as it sounds better than maintaining a set of patches. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:39:18PM +0200, Farid Hajji wrote: > > Same problem for BSD porters. This is _really_ annoying for every > non-Linux porter/maintainer out there. I'd strongly support such > a move; perhaps starting with a deprecation #warn-ing, and later > changing this to a hard #error. I'll raise the issue on Glibc mailing lists, and CC bug-hurd. Please make sure you people get to participate. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:13:32PM +0200, Jeroen Dekkers wrote: > On Sat, Oct 04, 2003 at 06:05:13PM +0000, Robert Millan wrote: > > I think we should disallow direct inclusion of in Glibc, any > > comments? > > There don't exist any headers in glibc, they come from > Linux. IIRC, Glibc build process takes them from specified location and installs them in /usr/include/linux/. So there's room to apply some patches. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 07:03:37PM +0200, Marcus Brinkmann wrote: > > That's all fine, I guess, but affects other systems beside GNU/Hurd just as > well. If headers needs to be protected against inclusion must > be decided by whoever provides these headers. This would be glibc in your > case. Of course. I just wanted to check with you people to see what the general opinion is. Since it sounds fine to you, I'll post to Glibc mailing lists in short. I'd like to hear Roland's opnion first, though. Roland, are you around? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
On Sat, Oct 04, 2003 at 06:16:47PM +0200, Marcus Brinkmann wrote: > On Sat, Oct 04, 2003 at 06:05:13PM +0000, Robert Millan wrote: > > I think we should disallow direct inclusion of in Glibc, any > > comments? > > This is not an issue related to the Hurd at all. If you think that this > should be done, for whatever reason, you need to talk to the glibc > maintainers. I know. But this seriously affects portability to non-Linux-based systems, which includes GNU/Hurd. I'm really sick of encountering programs that break because of arbitrarily including stuff. Today I just recieved a patch for a program I maintain that adds an #include on just to get the PATH_MAX macro. I'm going mad with this kind of stuff. If people really want Linux-specific features, let them define _USE_LINUX or something like that. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
disallow direct inclussion of
Hi folks! I think we should disallow direct inclusion of in Glibc, any comments? Sort of like: #ifndef _USE_LINUX # error "Never include directly; use standard headers instead." #endif If you (specialy Roland) like the idea, I can send it to the Glibc lists. (and write a patch). -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: libtool (branch-1-5) report
On Thu, Sep 25, 2003 at 11:10:30AM +0200, Alfred M. Szmidt wrote: >Thanks! Could you also try HEAD? It's not very clear wether the >next release will be 1.5.1 or 1.6, although 1.6 will be there >roughly in a pair of months. > > libtool from HEAD fails at one test (mdemo2-make.test), I didn't have > the time to check what went wrong, but will do that today. Note that libtool checks are known for not being very reliable. It may well be that the check fails for external unrelated factors. Try to repeat automatedly the build & check a few times, the results are likely to vary. >There's also the question that the "gnu*)" test case in libtool.m4 >doesn't have as many defined variables than other GNU-like >systems. Comparing to "kfreebsd*-gnu" and "knetbsd*-gnu", the >following are missing: > > shlibpath_overrides_runpath=no > dynamic_linker='GNU ld.so' > >Any comments on this? Perhaps we should ask the libtool >maintainers. > > shlibpath_overrides_runpath should be set. What to? I assume they're processed by gnu ld.so, then "no" is the right answer for all of GNU and friends? Btw could you send the patch for that? My "accept patch without signing papers" quota for libtool is reaching its limit. > What is dynamic_linker > used for? I only looked breifly at libtool, and it seems that it is > only used to print what linker we are using. If thats the case then I > think we should just stick with the default which is a bit more > informative then "GNU ld.so" (the default is "gnu0.3 ld.so"). Maybe we'd ask them, but I don't it really matters, we're always in time to change it later. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: libtool (branch-1-5) report
On Wed, Sep 24, 2003 at 09:19:10AM +0200, Alfred M. Szmidt wrote: > Good news, libtool (branch-1-5) compiles, and runs the testsuite on > GNU/Hurd without a single failure. It was compiled with gcc 3.2 and > binutils 2.14, running libc 2.3.2 (with a minor patch). And the > output of the compile and testsuite are inlined. Thanks! Could you also try HEAD? It's not very clear wether the next release will be 1.5.1 or 1.6, although 1.6 will be there roughly in a pair of months. There's also the question that the "gnu*)" test case in libtool.m4 doesn't have as many defined variables than other GNU-like systems. Comparing to "kfreebsd*-gnu" and "knetbsd*-gnu", the following are missing: shlibpath_overrides_runpath=no dynamic_linker='GNU ld.so' Any comments on this? Perhaps we should ask the libtool maintainers. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#156600: Processed: Partially fixed
tag 190732 - fixed thanks On Sun, Aug 17, 2003 at 08:48:11AM -0500, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > > tags 190732 + fixed > Bug#190732: hurd: non-priviledged user may crash filesystem > Tags were: patch > Tags added: fixed Hi Ognyan, In Debian BTS we use the "fixed" tag to indicate a bug has been fixed in NMU or other weird situations I can't recall. When a bug is fixed in upstream CVS there's no tag to indicate it, someone should just update the hurd package and close it. (Jeff, were you going at it?) btw thanks, we almost can build coreutils cleanly now :) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: ruby 1.8
On Sun, Aug 17, 2003 at 04:36:42PM +0200, Manfred Hansen wrote: > Hello, > > i have build the packages for ruby 1.8. > > They can download under > http://137238.vserver.de/hurd/ Thanks for your effort, but there's no need to do that. If the packages build cleanly the autobuilders will take them eventualy and upload them to the Debian archive. btw thanks to Michael Banck for fixing them! I was too busy to get into it back then :) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: e2fslibs for ext2fs?
On Thu, Aug 14, 2003 at 09:03:20PM +0200, Marco Gerards wrote: > > Ext2fs doesn't have a mkdir like function. It is all in libdiskfs. See > ext2fs/dir.c to find out how it works. Same for most other functions > you talk about. > > file_read doesn't exists for example. What libdiskfs does is using the > file pager to read the file contents. ok.. will have a look. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
e2fslibs for ext2fs?
Hi there, I recently came across the "e2tools" [1] package which is basicaly like "mtools" but for ext2. (btw I even made a Debian package [2] which is now used by GRUB to produce these nice GRUB rescue floppies automagicaly [3]) The interesting point for the Hurd is that e2tools uses library calls in e2fslibs to access the underlying ext2 filesystem. I don't have much clue with filesystem implementation so this might sound silly; Would it be feasible to rewrite the ext2fs server for using e2fslibs? At a fast glance, I can see interesting calls like: ext2fs_mkdir ext2fs_file_open ext2fs_file_get_size ext2fs_file_lseek ext2fs_file_read It'd probably be that e2fslibs brings ext3 support too.. [1] http://home.earthlink.net/~k_sheff/sw/e2tools/index.html [2] http://packages.debian.org/unstable/misc/e2tools.html [3] http://packages.debian.org/unstable/admin/grub-disk.html -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Status of ext2fs
On Sat, Aug 09, 2003 at 09:08:41PM +0200, Ireadyourmaillist wrote: > Hello, > > Does anyone know about the current status of the ext2fs server and the > problem of the filesystem size. There's an highly experimental patch; testers wanted; search the list archives and Savannah patch list for details. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [patch] compile and install hurd.ti
On Sun, Aug 10, 2003 at 04:24:41PM +0200, Alfred M. Szmidt wrote: > For the time being I think that we should compile and install hurd.ti > when installing the Hurd. Atleast untill ncurses gets updated and > includes our terminfo entry. What is putting ncurses on hold? Dickey is active and fast with patches, same for ncurses' Debian maintainer. btw, I recall seeing Hurd/Mach terminfo patches in ncurses debian package which are not merged upstream. Did someone send them to debian only? > 2003-08-10 Alfred M. Szmidt <[EMAIL PROTECTED]> > > * Makefile (install): New target. > > --- Makefile.~1.13.~ 2002-09-22 01:28:01.0 + > +++ Makefile 2003-08-10 08:51:16.0 + > @@ -1,5 +1,5 @@ > # > -# Copyright (C) 2002 Free Software Foundation, Inc. > +# Copyright (C) 2002, 2003 Free Software Foundation, Inc. > # Written by Marcus Brinkmann. > # > # This file is part of the GNU Hurd. > @@ -45,3 +45,7 @@ > #MIGSFLAGS += -imacros $(srcdir)/mutations.h > > include ../Makeconf > + > +# FIXME: Remove when ncurses includes out terminfo entry. > +install: > + -tic -o $(prefix)/share/terminfo -x $(srcdir)/hurd.ti > > > ___ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH][ALPHA 3] ext2fs and large stores (> 1.5G)
On Mon, Jul 21, 2003 at 04:36:11PM +0300, Ognyan Kulev wrote: > > Probably there are some advantages in using libstore instead of Unix API. Maybe.. but we can't fix every piece of software that uses Unix API to access block devices :) -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH][ALPHA 3] ext2fs and large stores (> 1.5G)
Hi Ognyan! On Mon, Jul 21, 2003 at 02:51:37PM +0300, Ognyan Kulev wrote: > > RELIABILITY > --- > > I put a great effort (and time) to assure that there will be no problems > with Alpha 3. Unfortunately, I still can't claim that. Data corruption > seems to be gone, but there are some strange hangs after an hour of > compiling glibc (on P4 1.6G) that I cannot look closely. For example, > the compilation is working in screen program window, but keyboard > doesn't respond, even Alt-F2 doesn't work (console server is running). > I connect to telnetd, do "ps ax", and after some printed lines, the > machine reboots... If you don't push the ext2fs server too much, there > is a chance you won't have problems. Are you running your patched server as the root filesystem? > E2FSPROGS > - > > e2fsprogs uses Unix API to work with partitions/images. Unfortunately, > we have a limit of 2G for files, so I've made an ugly patch for > e2fsprogs that uses libstore in e2fsck as "Hurd IO manager". Probably > when the patch is polished, I'll send it upstream. Why not fix the 2G limit instead? This adds more work in maintaining e2fsprogs code and is a hack that distracts from the real problem that needs fixing. Anyway, most people create their partitions for GNU from a GNU/Linux system so e2fsprogs shouldn't have much problem. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: A translator for the MINIX file system
On Sun, Jul 20, 2003 at 09:05:44PM +0200, [EMAIL PROTECTED] wrote: > Of course, I will continue working at the translator, and will start in > time a porting of the two utilities `mkfs.minix' and `fsck.minix' from > `util-linux'. They were ported already, by Guillem Jover. The patch is merged in debian package (in unstable): http://packages.debian.org/util-linux It is actualy contained in the util-linux_*.diff.gz file. If someone has time to, it'd be nice to update it for latest upstream version of util-linux and send it to the upstream maintainers. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)
On Fri, Jul 18, 2003 at 04:24:17PM +0200, Gaël Le Mignot wrote: > > My idea was to implement the driver in userspace and force X to use it. > > Following this dessign, we could end up seeing X running as non-root. > > That would require a huge amount of work I fear, especially if we want > to support hardware acceleration at the end (like xvideo or dri), but > I agree it's the best long-term solution. Yes. But note the hardware acceleration concept is a dirty hack as a whole. It'd be nice to support it since this is the direction the world takes, but not critical. I can live happily with a screen that is simply a matrix of pixels. > > What we could do is writing the keyboard, vga etc translators, but don't > > implement the actual hardware I/O on them yet. Instead, just use them for > > resource management. > > I was thinking about something like that too, at least until we move > to L4 (implementing user-space drivers on top of Mach is tricky). I started the "user-drivers" project at Savannah some time ago, and started writing simple drivers from scratch. At this point, I think it'd be better to use Oskit instead. To the people who have played with Oskit already, do you think it's viable to use it as a backend for userspace drivers? -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)
[ I'm changing CC to [EMAIL PROTECTED], so it gets archived too ] Hi Gael, On Fri, Jul 18, 2003 at 11:41:10AM +0200, Gaël Le Mignot wrote: > Hello Robert! > > Just to remind you that it's not the console _server_ which conflicts > with X, but the console _client_ using vga or a keyboard driver. Your > mail wasn't clear at all about that. ouch.. well, whatever it's called, I was referring to the program that uses hardware resources :) > I don't think the correct solution would be for X and the console to > directly speak to each other like X saying to the console client "stop > please", but rather a per-ressource (VGA, keyboard, mouse) way to say > "I want exclusive access to this ressource". The console client itself > would just agree to give to the access to X, or something like that. Ah, ok. IIRC last time we discussed this I proposed something like having the userspace drivers as translators that either block a second process from accessing them, or queue the requests somehow. My idea was to implement the driver in userspace and force X to use it. Following this dessign, we could end up seeing X running as non-root. What we could do is writing the keyboard, vga etc translators, but don't implement the actual hardware I/O on them yet. Instead, just use them for resource management. > It would be nice too if we could "switch" at run-time from X to > console and vice-versa like we can do on GNU/Linux. That feature is (on monolithic kernels) VT_ACTIVATE. X tells the (monolithic) kernel to bring up the console with the ioctl VT_ACTIVATE on /dev/console or another arbitrary device. (see my patch to disable this feature for systems without VT_ACTIVATE in xfree86's debian/patches dir) Once we come up with our own interface, adding a replacement for VT_ACTIVATE shouldn't be too hard. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Xfree86 and console server (and VT_ACTIVATE, etc)
We just spoke in IRC about a possible solution of the Xfree86 problem with the console server. I propose something like this: I don't know the right way to fix the problem. nyu might know, though, since he knows a bit of the X code. Basically, X needs to signal the console to get out of the way. jbailey, azeem: yeah, i played with _that_ particular code some time ago the VT_ACTIVATE thing any questions? :) oh, heard about that one nyu: Yes. Will you make it work? =) jbailey: what's the problem :) i haven't tried with oskit-mach As I understand it, starting X while the console is running results in suckage. It needs to not do that. =) uhm.. no, VT_ACTIVATE is for telling X to switch into a text terminal. i don't [know] where should X tell the console server it should freeze itself i suggest to make the console listen in /dev/something, and when X opens /dev/something, console stops using the keyboard or screen. when /dev/something is closed, it comes back or maybe in /var the same simple interface could be used for VT_ACTIVATE -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Poject
Hi Prasanna, This is a collaborative open development project, please keep the CC to public list when discussing public issues. On Tue, Jul 15, 2003 at 07:47:45AM -0700, prasanna wakhare wrote: > Sir, > I have read the page ,perhaps it need some time to > read and understand the whole thing,But how > can i contribute to yr project , > means it needs some help ,I really devote my time hard > > to perform well But how can i get involved, > if possible plz reply. > I will mail you again after thoroghly reading the > documentation. I'd suggest you start installing the Hurd-based GNU operating system and playing with it. Depending on your skills and interests you'll find different tasks on which you could help. For example, if you're interested on multi-server system core dessign, I suggest you read source code for the Hurd, Glibc, GnuMach, etc. Then find out what needs to be fixed and submit your patches to this list. Or if you are interested in having working applications for GNU, you could also dedicate your time to porting the software that you miss for that platform. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Poject
Hi Prasanna, The Hurd is a GNU project, not a Linux project. It is GNU's replacement for the Unix kernel (or other unix-like kernels, like Linux), and constitues the base of the GNU operating system. You're welcome if you want to help, please see http://hurd.gnu.org/ for details about the Hurd. You might find interesting projects for the Hurd in the CVS TODO files or in Savannah's task list. (see http://savannah.gnu.org/projects/hurd) On Mon, Jul 14, 2003 at 07:15:54AM -0700, prasanna wakhare wrote: > Hello Sir, > I am a postgraduate student of computer science in > VJTI BOMBAY,INDIA.Its 7th ranking and reputed college > college in india. > I have done UniX simple command interpreter as my > project in graduation > it integrates some features from C,bourne,korn etc. > i can send u code if u want.I also design device > driver for PC-console speaker,a very simple filesystem > and some simple LKM. > I am searching a good project for My postgraduate > programme. > Althogh its very confussing to see it on internet > ,they seems very obscure or not detail explaination is > given.I have given my capabilities as above. > My project is 1-year duaration although i can make 2 > or 3 small project even as second altenative, > But i need somebody's guidance for a very specific > domain for the project. I can efficiently devote my 1 > year time for that.I > want to do work for linux but finds myself to be very > beginer when i see some projects over net. > please help me,giving some information about current > linux projects or if possibility of paricipation of > myself in some community.Or any > type of help u can provide. > > thank You > Eagerly waiting for your positive reply > > > __ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ___________ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Design your own Linux-shoes
On Sat, Jul 12, 2003 at 04:36:59AM +0200, Farid Hajji wrote: > > > Please, let's change the posting policy of our lists > > > to subscribers only. I know this has been discussed at > > > length so many times before, yet no-one at gnu.org seems > > > to care. > > > > No, it's useful for non-subscribers to send messages. > > That doens't happen so often. If we grep out all known > subscribers, what does remain? My messages, for example. They're tagged by mailman as message from non-subscriber. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Design your own Linux-shoes
On Sat, Jul 12, 2003 at 02:19:14AM +0200, Farid Hajji wrote: > > Please, let's change the posting policy of our lists > to subscribers only. I know this has been discussed at > length so many times before, yet no-one at gnu.org seems > to care. No, it's useful for non-subscribers to send messages. Also some people have mail configured to send mail from a different address than their reply address is. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: mouse device
On Fri, Jul 04, 2003 at 09:07:54PM +0100, Sam Halliday wrote: > hi there, > > i can get xf86cfg to give me its classic black-grey pattern when i start > up, but the pointing device does not work. i realised that the > /dev/mouse (or /dev/psaux) does not exist, and i cannot make it with > MAKEDEV. > > could somebody please tell me how to get the mouse device? set the translator, it should be in /hurd/mouse if you're using the debian package of the hurd. btw, you upstream CVS people could please commit the mouse/kbd patch from the debian hurd_*.diff.gz? -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: why was um-pppd removed?
On Fri, Jun 27, 2003 at 07:03:52PM +0200, Neal H. Walfield wrote: > > but modern *BSDs use a kernel-space "Linux approach". are you sure > > um-pppd is still maintained? > > Last update was on June 19, 2003 [1]. I attempted to submit my > patches to Brian several times, however, I never got any type of > response. > > [1] http://www.awfulhak.org/~brian/ ok, I just sent an RFP. how big are your patches? are they easily maintainable? if we don't hear anything from Brian maybe we could start a project at Savannah ala Oskit. -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: why was um-pppd removed?
On Fri, Jun 27, 2003 at 06:06:25PM +0200, Marcus Brinkmann wrote: > > Interface compatible to what? The um-pppd package comes from BSD, and the > pfinet tunnel device is interface compatible to BSD's tunnel device. oh. I didn't know about tunnel devices; that probably confused me. > So we > already do what you suggest: The traditional userland (um-pppd) is not > maintained by us, and we provide a compatible interface in the Hurd. We > just don't use the Linux approach but the BSD approach, which is more in > line with our design. but modern *BSDs use a kernel-space "Linux approach". are you sure um-pppd is still maintained? -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd package needs an update (was: Re: [Patch #1606] Overhauldebian/rules)
On Sun, Jun 22, 2003 at 06:47:43PM +0200, Robert Millan wrote: > On Sat, Jun 21, 2003 at 08:28:43PM -0400, Jeff Bailey wrote: > > If someone beats me to it, then great. > > no chance, still on exams (and lucky that i found a minute to check mail) finished with exams! :) looking at the package, i think it'd be nice to re-do debian/rules to use more modern packaging with debhelper and dbs-style building. do you mind if i rewrite debian/rules? I don't have much experience with dbs-style packaging though. Jeff, what do you suggest? cdbs? -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: why was um-pppd removed?
On Thu, Jun 26, 2003 at 01:00:53AM +0200, Farid Hajji wrote: > > If um-pppd is unwelcome in the debian archives, why not > add it temporarily in the hurd sources, perhaps with the > intent of turning it later into a ppp translator? sounds like a good idea; then we don't have to maintain the part of ppp that traditionally lived in userland, since we have it in debian's ppp package (which is kernel-agnostic) i don't have time (or interest) for this myself. could someone add to the Hurd's task list in Savannah about writing an interface-compatible ppp translator? (yes, i know this implies some redessign in the interface between pfinet and mach devices, but this is necessary anyway when we want to support userspace drivers. e.g: /dev/eth0) -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd package needs an update (was: Re: [Patch #1606] Overhauldebian/rules)
On Sat, Jun 21, 2003 at 08:28:43PM -0400, Jeff Bailey wrote: > I went about this yesterday, and discovered that tetex-bin isn't usable > in the archive. Decided that solving that was a task for Monday as I > have a guest in town. tetex-bin has been broken a pair of times for all arches (see the changelog, first flex build error, then postinst fails) in the last two revisions. are you using the latest version? > If someone beats me to it, then great. no chance, still on exams (and lucky that i found a minute to check mail) -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Hurd package needs an update (was: Re: [Patch #1606] Overhaul debian/rules)
On Tue, Jun 10, 2003 at 07:41:20PM +0200, Robert Millan wrote: > Package: hurd > Severity: wishlist > Tags: patch with this one there are six bugs for package hurd in the BTS that either are fixed in CVS or have an attached patch. a fast look brought me: 190732, 156600, 184344, 149309, 177486, 196913 are you going to upload a new package soon? -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [Patch #1606] Overhaul debian/rules
Package: hurd Severity: wishlist Tags: patch since this is debian-related stuff it should be in debian BTS, too. i'm adding it. On Tue, Jun 10, 2003 at 01:16:55PM -0400, [EMAIL PROTECTED] wrote: > > Patch #1606 has been updated. > > Project: > Category: None > Status: Open > Summary: Overhaul debian/rules > > Follow-Ups: > > Date: Tue 06/10/2003 at 20:16 > By: ogi > > Comment: > In short, this is what this patch changes: > > * New package hurd-doc that is Architecture: all. > * hurd-doc includes HTML output generated by makeinfo --html and registers itself in > doc-base. texi2html is better choice, but it's not part of the GNU project so I > didn't use it. > * hurd-dbg package that installs *.so.* files in /lib/debug > * /lib/hurd/hurd.msgids is part of hurd and rpctrace always includes it. Though it > is questionable what should be it's location. > > Someone with more knowledge about Debian packaging and the Hurd package should look > at it too. > > Changing the current .diff.gz file is trivial. > --- > > --- > For more info, visit: > > http://savannah.gnu.org/patch/?func=detailpatch&patch_id=1606&group_id=30 > > > _______ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd -- Robert Millan ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
