Development time used for another project
Hello Hurd hackers! Some time ago I offered to work as a full time developer of the Hurd. However, about 4 months ago or so I got caught by a childhood dream project and started working on MININIM, the advanced free software implementation (I wrote from scratch) of Jordan Mechner's masterpiece game, Prince of Persia (1990 IBM-PC port). Now, it's already a complete replacement for the original and superior in several areas. Here's a link to its web page: http://oitofelix.freeshell.org/mininim/ I want to apologize with you for not being able to work as I expected to as a Hurd developer. Sorry for the noise. All the best, See you around. -- 88888 FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] 8 8 F http://oitofelix.freeshell.org/ 8 mailto:oitofe...@gnu.org 8 8 F irc://chat.freenode.org/oitofelix 8 F xmpp://oitofe...@riseup.net - MININIM: http://oitofelix.freeshell.org/mininim/ - TM86: http://oitofelix.freeshell.org/terminal-matrix-8086/ - QDot86: http://oitofelix.freeshell.org/qdot-8086/ - GNU ccd2cue: http://www.gnu.org/software/ccd2cue/ Please, support my work: http://oitofelix.freeshell.org/funding.html pgp3qNNHR2Wrn.pgp Description: Assinatura digital OpenPGP
Re: libusb+librump patch
Hello Antti! Em Wed, 30 Sep 2015 20:57:06 + Antti Kantee escreveu: > So you are wanting libusb to work against a rump kernel? It'd be nice. It's my first attempt to make anything work against a rump kernel on Hurd. > A rump kernel does not, at least currently and AFAIR/AFAIK, provide > ugen, so that won't work now. How unfortunate! :-( > If you do need libusb, adding a ugen component shouldn't be too > difficult, though. How could I help with that? Is it worth? > (but I sort of hate ugen ;) I want to give USB support to Hurd. I know it sounds generic, but any working initial implementation will do as a starting point. Do you have any alternative suggestions? > What sort of general architecture are you planning in the Hurd case? Sorry, I don't understand the question. -- 8 F Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] 8 8 F http://oitofelix.freeshell.org/ 8 mailto:oitofe...@gnu.org 8 8 F irc://chat.freenode.org/oitofelix 8 F xmpp://oitofe...@riseup.net - GNU ccd2cue maintainer - GNU Savannah hacker - GNU webmaster - GNU web translation team coordinator (Brazilian Portuguese) - GNU audio and video maintainer - DMOZ free software editor (Portuguese) - UFU FAMAT PET member - SDF Public Access UNIX System ARPA member - Riseup user and supporter Please, support my work: http://oitofelix.freeshell.org/funding.html [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpDlsOAOrK1b.pgp Description: Assinatura digital OpenPGP
Re: libusb+librump patch
Hello Robert! Em Wed, 30 Sep 2015 22:37:50 +0200 Robert Millan escreveu: > I suggest you export RUMP_VERBOSE=2 to get verbose output from the > Rump kernel. Thank you for the suggestion. Here is the output: libusb: 0.00 debug [libusb_init] libusb-1.0.9 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.17 (RUMP-ROAST) total memory = unlimited (host limit) timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 cpu0 at thinair0: rump virtual cpu cpu1 at thinair0: rump virtual cpu root file system type: rumpfs kern.module.path=/stand/i386/7.99.17/modules mainbus0 (root) pci0 at mainbus0 bus 0 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok vendor 8086 product 2560 (host bridge, revision 0x01) at pci0 dev 0 function 0 not configured vendor 8086 product 2562 (VGA display, revision 0x01) at pci0 dev 1 function 0 not configured uhci0 at pci0 dev 2 function 0: vendor 8086 product 24c2 (rev. 0x01) uhci0: interrupting at pausebreak usb0 at uhci0: USB revision 1.0 uhub0 at usb0: vendor 8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 3 function 0: vendor 8086 product 24c4 (rev. 0x01) uhci1: interrupting at pausebreak usb1 at uhci1: USB revision 1.0 uhub1 at usb1: vendor 8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 4 function 0: vendor 8086 product 24c7 (rev. 0x01) uhci2: interrupting at pausebreak usb2 at uhci2: USB revision 1.0 uhub2 at usb2: vendor 8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered vendor 8086 product 244e (PCI bridge, revision 0x81) at pci0 dev 5 function 0 not configured vendor 8086 product 24c0 (ISA bridge, revision 0x01) at pci0 dev 6 function 0 not configured vendor 8086 product 24cb (IDE mass storage, interface 0x8a, revision 0x01) at pci0 dev 7 function 0 not configured vendor 8086 product 24c3 (SMBus serial bus, revision 0x01) at pci0 dev 8 function 0 not configured vendor 8086 product 24c5 (audio multimedia, revision 0x01) at pci0 dev 9 function 0 not configured vendor 8086 product 1039 (ethernet network, revision 0x81) at pci0 dev 10 function 0 not configured uhub1: device problem, disabling port 2 libusb: 6.64 debug [usbi_add_pollfd] add fd 4 events 1 libusb: 6.64 debug [libusb_init] created default context libusb: 6.64 debug [libusb_get_device_list] libusb: 6.64 debug [obsd_get_device_list] libusb: 6.66 debug [libusb_exit] libusb: 6.66 debug [libusb_exit] destroying default context libusb: 6.66 debug [usbi_remove_pollfd] remove fd 4 The relevant message is: "uhub1: device problem, disabling port 2". That, I think, is the only difference between running 'listdevs' with and without a USB device attached to the system. Any ideas? > 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. -- 8 F Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] 8 8 F http://oitofelix.freeshell.org/ 8 mailto:oitofe...@gnu.org 8 8 F irc://chat.freenode.org/oitofelix 8 F xmpp://oitofe...@riseup.net - GNU ccd2cue maintainer - GNU Savannah hacker - GNU webmaster - GNU web translation team coordinator (Brazilian Portuguese) - GNU audio and video maintainer - DMOZ free software editor (Portuguese) - UFU FAMAT PET member - SDF Public Access UNIX System ARPA member - Riseup user and supporter Please, support my work: http://oitofelix.freeshell.org/funding.html [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpdt_Wr0Nqsx.pgp Description: Assinatura digital OpenPGP
Re: Shortest path to significant improvement in hardware support
Hello, Robert! Em Tue, 29 Sep 2015 22:56:59 +0200 Robert Millan escreveu: > 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? Not really --- I mean USB in general. However, if I had to choose, I'd pick USB mass storage devices. > 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? Somewhat. I'm not quite concerned about #2, because I'm assuming the majority of people run Hurd on their personal computers. #1 is more worrying, but I think we can do without it --- at least as a proof of concept --- to get any USB working on Hurd at all. Furthermore, it might be the case that for some device classes and common uses multiplexing isn't that critical. > 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. That's true. However, I prefer to start with the least complex approach at first, and then study its practical limitations and then develop it further, if needed. Moreover, in order to grasp every concept needed to make the ideal Hurd USB implementation, I need to reduce complexity and handle issues in isolation, learning by composition in small chunks and in a progressive manner. -- ,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) http://oitofelix.freeshell.org/ `-'(. .)`-' irc://chat.freenode.org/oitofelix \_/ xmpp:oitofe...@riseup.net GNU ccd2cue maintainer GNU Savannah hacker GNU web translation team coordinator (Brazilian Portuguese) GNU audio and video maintainer DMOZ free software editor (Portuguese) UFU FAMAT PET member [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpZNN5E0UMzI.pgp Description: Assinatura digital OpenPGP
libusb+librump patch
Hello, GNU Hurd hackers!
Based on Robert Millan's mplayer rump patch, I was able to make a
patch to successfully build libusb-1.0 on Hurd linking it to librump.
The patch is attached. To try it, save the patch file in the current
working directory and from there follow these steps:
$ su -c 'apt-get install libbsd-dev'
$ wget
http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.9/libusb-1.0.9.tar.bz2
$ tar xf libusb-1.0.9.tar.bz2 && cd libusb-1.0.9
$ patch -p1 < ../libusb-1.0.9+rump.patch
$ rm config.guess
$ autoreconf -i
$ ./configure --enable-debug-log && make
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. If
I can't make libusb work properly when directly linked to librump, I
clearly won't be able to make a translator indirection work.
A problem at a time.
--
,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) http://oitofelix.freeshell.org/
`-'(. .)`-' irc://chat.freenode.org/oitofelix
\_/ xmpp:oitofe...@riseup.net
GNU ccd2cue maintainer
GNU Savannah hacker
GNU web translation team coordinator (Brazilian Portuguese)
GNU audio and video maintainer
DMOZ free software editor (Portuguese)
UFU FAMAT PET member
[GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily
match those of the GNU project. Hereby I express my own opinion,
style and perception, in good faith, aiming the betterment of GNU.
diff -Naur libusb-1.0.9/configure.ac libusb-1.0.9+rump/configure.ac
--- libusb-1.0.9/configure.ac 2012-04-20 03:44:27.0 -0300
+++ libusb-1.0.9+rump/configure.ac 2015-09-30 00:59:19.0 -0300
@@ -62,6 +62,12 @@
AC_MSG_RESULT([NetBSD (using OpenBSD backend)])
backend="openbsd"
;;
+*-gnu*)
+ AC_MSG_RESULT([NetBSD (using OpenBSD+rump backend)])
+ backend="openbsd"
+ LIBS="$LIBS -lbsd -lrump -lrumpuser -lrumpvfs -lrumpdev -lrumpdev_pci -lrumpdev_usb -lrumpdev_pci_usbhc -lrumpdev_ugenhc"
+CPPFLAGS="$CPPFLAGS -D__RUMP__"
+ ;;
*-mingw*)
AC_MSG_RESULT([Windows])
backend="windows"
diff -Naur libusb-1.0.9/libusb/os/openbsd_usb.c libusb-1.0.9+rump/libusb/os/openbsd_usb.c
--- libusb-1.0.9/libusb/os/openbsd_usb.c 2012-04-20 03:44:27.0 -0300
+++ libusb-1.0.9+rump/libusb/os/openbsd_usb.c 2015-09-30 00:59:16.0 -0300
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2011 Martin Pieuchot
+ * Copyright (c) 2015 Bruno Félix Rezende Ribeiro
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -26,7 +27,32 @@
#include
#include
-#include
+#ifdef __RUMP__
+ #include
+ #define RUMP_SYS_OPEN
+ #define RUMP_SYS_CLOSE
+ #define RUMP_SYS_IOCTL
+ #define RUMP_SYS_READWRITE
+
+ #undef O_RDONLY
+ #define O_RDONLY RUMP_O_RDONLY
+ #undef O_RDWR
+ #define O_RDWR RUMP_O_RDWR
+ #undef O_WRONLY
+ #define O_WRONLY RUMP_O_WRONLY
+
+ #undef ENOENT
+ #define ENOENT RUMP_ENOENT
+ #undef ENXIO
+ #define ENXIO RUMP_ENXIO
+
+ #include
+ #include
+ #include "rump_ioccom.h"
+ #include "rump_usb.h"
+#else
+ #include
+#endif
#include "libusb.h"
#include "libusbi.h"
@@ -47,6 +73,10 @@
/*
* Backend functions
*/
+
+#ifdef __RUMP__
+static int obsd_init(struct libusb_context *ctx);
+#endif
static int obsd_get_device_list(struct libusb_context *,
struct discovered_devs **);
static int obsd_open(struct libusb_device_handle *);
@@ -89,7 +119,11 @@
const struct usbi_os_backend openbsd_backend = {
"Synchronous OpenBSD backend",
- NULL,/* init() */
+#ifdef __RUMP__
+ obsd_init, /* init() */
+#else
+NULL, /* init() */
+#endif
NULL,/* exit() */
obsd_get_device_list,
obsd_open,
@@ -128,
Shortest path to significant improvement in hardware support
Hello, Hurd hackers! 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? Ps: Sorry for the long delay, but as you can see by my signature, since my introductory message I've got some titles that require a significant amount of work. Nevertheless, I'll make sure Hurd gets at least 50% of my available time and brainwidth. That is a full-time half-time developer. ;-) -- ,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) http://oitofelix.freeshell.org/ `-'(. .)`-' irc://chat.freenode.org/oitofelix \_/ xmpp:oitofe...@riseup.net GNU ccd2cue maintainer GNU Savannah hacker GNU web translation team coordinator (Brazilian Portuguese) GNU audio and video maintainer DMOZ free software editor (Portuguese) UFU FAMAT PET member [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpIddofnG1QC.pgp Description: Assinatura digital OpenPGP
Re: Full-time developer available
Hello Robert! Em Tue, 15 Sep 2015 22:11:15 +0200 Robert Millan escreveu: > I think it's mostly Zheng Da's merit. Thank you Zheng Da! :-) > 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. > 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. -- ,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) http://oitofelix.freeshell.org/ `-'(. .)`-' irc://chat.freenode.org/oitofelix \_/ xmpp:oitofe...@riseup.net GNU ccd2cue maintainer GNU web translation team coordinator (Brazilian Portuguese) GNU audio and video maintainer DMOZ free software editor (Portuguese) UFU FAMAT PET member [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgp7_Jxt1rVtE.pgp Description: Assinatura digital OpenPGP
Full-time developer available
Hello, GNU Hurd hackers! I'm available to work on free software things of my choice full time for at least the next six months. Besides helping the GNU project and the FSF with some infrastructural work and campaigns, I've decided to use all my remaining time to hack on the GNU Hurd. I'm a beginner to GNU Hurd, but I have plenty of time and I'm willing to learn whatever is necessary to get the job done. I've been playing around with my Hurd Box and devouring the Hurd wiki and related documentation for a few days by now, but I think it's time to start working towards a clear goal in order to keep myself on track. 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. I know you all are busy people, but I'd appreciate pretty much any form of mentoring or advice I can get. Thank you in advance! Footnotes: [0] http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/driver_glue_code/ -- ,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) http://oitofelix.freeshell.org/ `-'(. .)`-' irc://chat.freenode.org/oitofelix \_/ xmpp:oitofe...@riseup.net GNU maintainer: ccd2cue DMOZ free software editor (Portuguese) UFU FAMAT PET member [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpsX1BIOO8XC.pgp Description: Assinatura digital OpenPGP
