Re: Updating the hurd in Guix

[Olaf Buddenhagen]

Hi,

On Tue, Feb 15, 2022 at 01:59:11AM +, Damien Zammit wrote:

> Yes, that is the usual way to manage changes, but the entire NetBSD
> source tree is very large, and we only have about 100 lines of changes
> in total that I am trying to upstream.
[...]

I feel like I've heard this story before... A long time ago, when I was
involved with the KGI project, they were afraid of importing the entire
Linux source tree in CVS to do their modifications -- so instead they
build their own fragile, slow, under-documented etc. patch system on
top...

Of course I'm sure Debian's system is a lot less problematic than what
KGI rolled on their own -- but on the other hand, I feel that there is
even less justification for such manoeuvres nowadays, considering how
effortlessly Git deals with large source trees...

Putting it more bluntly: so the NetBSD source tree is large... And?

This is not my call to make of course: but I'd strongly recommend to
consider using revision control the way it's meant to be used: rather
than working around something that -- best I can tell -- isn't even a
problem to begin with...

-antrik-

Re: Updating the hurd in Guix

[Olaf Buddenhagen]

Hi,

On Sat, Feb 12, 2022 at 11:28:03PM +, Damien Zammit wrote:

> I could create a github repo that contains everything for rump in one repo,
> but it would take time and would be easier to do once the netbsd src patches
> are upstreamed, so we would not need to maintain separate patches.

Admittedly without having followed what you actually did there, I have
to wonder: why would in be easier? Isn't a Git branch the obvious way to
manage non-upstream modifications?...

-antrik-

Re: A deferred authorization-granting translator

[Olaf Buddenhagen]

Hi,

On Wed, Dec 29, 2021 at 12:56:23PM +0100, Dr. Arne Babenhauserheide wrote:

> echo HELLOWORLD > /hello && \
> settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) 
> --groupname=user

The `-c` is redundant: you know the node already exists, as you just
wrote to it...

(Also, since you probably assumed that there is no pre-existing
translator when writing, arguably the `-g` is redundant as well...)

> It also starts a daemon that will remove the group again after 5
> minutes (modelled after the temporary permissions to run privileged
> without password granted by sudo).

That's not terribly useful: the program might have exec'ed or forked in
the mean time, or otherwise handed off the authority...

To have an enforceable timeout, you'd probably need some sort of custom
auth token with a bilt-in self-destruct, or something along these
lines... (Haven't thought about it much, though.)

More generally, my intuition is that the `auth` mechanism should be at
the heart of this: the whole "find PID and check its groups" approach
doesn't feel quite right... Though frankly, I can't really say much
beyond that right now.

> Accesses from two different translators can currently race for the
> reply. To fix this, the translator should write the PID and a random
> LABEL into the request. The program should repeat that label for
> replies to ensure that the reply and request can be matched. If
> receiving a non-matching reply, it MUST be written into the grant
> again after a random delay to enable a matching translator to
> retrieve the grant.
> REQUEST: PID LABEL
> GRANT: RET LABEL (RET=0 is success)
> LABEL=$RANDOM
>
> The system assumes having a single permission granting program per
> user. For a setup with multiple unconnected sessions per user (like
> several TTYs) the permission granting program needs to coordinate
> between these.

I'm pretty sure there must be a more Hurdish (and robust) way of
handling this communication... But again, haven't thought much about it.

Either way, it's good that you are looking into this: it's bringing up
interesting questions :-)

-antrik-

Re: A few questions: Libre SoC, website, Rust

[Olaf Buddenhagen]

Hi,

On Wed, Aug 19, 2020 at 11:40:32AM +0200, Jan Wielkiewicz wrote:
> Dnia 2020-08-19, o godz. 10:41:42 Samuel Thibault  
> napisa??(a):

> > There seems to be some move in there, see

> > https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html

> Yes, I saw this, but nothing especially indicates they will make the
> trademarks more user-friendly.

FWIW, Mozilla has always been weird with trademarks... Having an
independent foundation take charge instead certainly offers hope that
the situation will improve down the road.

-antrik-

Re: kernel panic in gsync_wait

[Olaf Buddenhagen]

Hi,

On Fri, Nov 04, 2016 at 12:14:27PM -1000, Brent W. Baccala wrote:

> How do we want to handle fixed bugs, like this gsync problem?  Should we
> open and close a bug report, just so it's documented in the bug database?
> I can open the bug, of course, but I don't have permission to close it...

Nah, the tracker is not supposed to be a complete history of all issues
ever... It's just to keep track of known open issues.

-antrik-

Re: gnumach copyright assignment

[Olaf Buddenhagen]

Hi,

On Thu, Oct 27, 2016 at 11:04:26PM +0300, Kalle Olavi Niemitalo wrote:

> | 2. Developer will report occasionally, on its initiative and whenever
> | requested by FSF, the changes and/or enhancements which are covered by
> | this contract, and (to the extent known to Developer) any outstanding
> | rights, or claims of rights, of any person, that might be adverse to
> | the rights of Developer or FSF or to the purpose of this contract.
> 
> Firstly, it seems unfair that, having given software to the FSF,
> I would have a permanent duty to report claims of adverse rights,
> while others who gave nothing would have no such duty.

Well, this clause suffers from a bad case of legalese, so I'm not sure
what it actually entails... (Which is of course a problem in itself.)

I would assume though that it only pertains to the contributions you
made covered by the assignment? I don't see how that would be unfair...

-antrik-

Re: Mach "pipe" between parent and child

[Olaf Buddenhagen]

Hi,

On Tue, Oct 25, 2016 at 05:59:34PM -1000, Brent W. Baccala wrote:

> What is the best way to fork() a child and have a Mach receive right on the
> parent connected to a send right on the child?

I wonder whether it's possibly to just wrap the send right in a fake
file descriptor, so fork() clones it automatically?...

-antrik-

Holy war (was: libpager multi-client support)

[Olaf Buddenhagen]

Hi,

On Mon, Oct 17, 2016 at 09:51:41PM -1000, Brent W. Baccala wrote:

> I've been thinking more about the data structures involved with the new
> libpager code, and they're complex enough that I'd like to write them in
> C++11.

Yay, flamebait! ;-)

Two years ago, I would have said something along these lines: C++ does
certainly have some strong point; but at the same time it's a very ugly
language, which is not universally considered an improvement. Even *if*
we agreed it was slightly better all in all, it's probably not worth the
costs.

But that was two years ago. Today my reply is: why even consider C++,
when there is Rust?

Rust offers the same level of efficiency; about the same level of
expressiveness (I'd say higher, but I might be biased); much, *much*
better safety; and while the initial learning curve is a bit steep, it
doesn't have any of the hidden complexity and countless pitfalls.

Rust's slogan is, "fast, reliable, productive: pick three" -- and it
delivers. I honestly believe it is a game-changer; and in my opinion the
Hurd would do good to start using Rust sooner rather than later. It
would gain a major edge: not only from the inherent productivity boost;
but also from increased attractiveness to developers.

While the Hurd wouldn't be the first operating system employing Rust, it
would be (to the best of my knowledge) the first general-purpose system
to employ Rust as a tool to meet its own unique goals, rather than just
"it's written in Rust" as the *only* selling point.

There is just one little problem right now: Rust hasn't been ported to
the Hurd yet. Whoopsie... ;-)

-antrik-

Re: Fully loadable device drivers

[Olaf Buddenhagen]

Hi,

On Mon, Oct 03, 2016 at 02:09:40PM +0300,  
??  wrote:

> Sorry, maybe I'm posting to wrong mailing list..

Probably. L4 never had in-kernel device drivers -- nor did any of the
other options that were being stipulated here. In fact this list has
been out of commission for a long time. bug-hurd is the right list for
this kind of discussion.

> I can't get the reason why Hurd development chose the way of compiling
> drivers with the kernel, same as linux.

Nobody actually *chose* this -- it's just what was inherited with the
Mach legacy. We want userspace drivers going forward, and indeed we
already have them for network devices. It just needs to be done for
other device classes. Wanna help? :-P

> It looks like an another boring buisness trick of foundations.

Err, what?

> if drivers would be totally independent from the kernel,

They can't be totally independent. They can (and should) run in separate
processes, though.

-antrik-

PS. Please don't send HTML mail.

Re: gnumach copyright assignment

[Olaf Buddenhagen]

Hi,

On Mon, Sep 26, 2016 at 10:34:00PM +0200, Samuel Thibault wrote:

> Oddly enough, in the fencepost copyright file, I see assignments for
> GNUMACH, but not for MIG.

Yes, AIUI a gnumach assignment is supposed to cover MiG contributions as
well...

-antrik-

Re: gnumach copyright assignment

[Olaf Buddenhagen]

Hi,

On Thu, Sep 22, 2016 at 08:45:58PM +0300, Kalle Olavi Niemitalo wrote:
> Olaf Buddenhagen <olafbuddenha...@gmx.net> writes:

> > The FSF doesn't actually require assignments for gnumach -- almost all
> > of gnumach is foreign code without FSF copyright anyway...
> 
> Thank you.  I had assumed that the old Mach code was
> grandfathered in, and that the FSF would require copyright
> assignments for any new additions.

No, that really wouldn't make too much sense: since gnumach code is
generally under a very permissive license, there is no need for the FSF
to hold copyright to allow for license changes or to prosecute license
violations...

> What does the FSF require for GNU Mach patches, then?
> A license grant and a signed employer disclaimer, perhaps?

That's actually a good question... Traditionally, most projects just
assume that if people contribute patches to files with a free software
license statement, that implies they have the right to do so. More
recently, many projects have moved to a more explicit "Developer's
Certificate of Origin".

Since almost all projects managed by the FSF require copyright
assignments, I'm not sure this has been considered at all. Maybe we
should bring it up -- but for now, I guess it's fine if you just send
the patches...

> I assume a dual license under GPLv2-or-later and the "MIT License"
> (the same terms as in xen/public/COPYING) would be acceptable.

Since MIT-style licenses are compatible with GPL (and pretty much any
other license), dual-licensing really makes little sense... I'm stumped
why some projects consider it a good idea.

When providing patches to existing files, just keep whatever is already
there; and if you add new files, go with the variant most commonly used
in existing files.

> Does the same policy apply to MIG as well?

Since it's formally part of gnumach, I *assume* the same policy
applies...

BTW, this is slightly off-topic: but AIUI, your main objection to
signing a copyright assignment is the requirement to provide updates on
your employer? Just in case it isn't clear: this is only really relevant
when you actually keep contributing after an employment change -- it's
not like you have to keep informing the FSF of your status forever just
because you contributed something in the past...

(If your are really weary, I think you could even do an assignment only
for past contributions -- though that would be pretty annoying I think,
as you'd have to renew it every time you make further contributions...)

-antrik-

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Olaf Buddenhagen]

Hi,

On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun  wrote:

> > This was famously shown with the example of the
> > firmlink translator used in /tmp, which would cause the removal of
> > any file targeted by the firmlink on /tmp cleanup during system
> > startup.
>
> I see that.  It seems to still have that problem.  I created a directory
> /root/baitdir, and put in it a file named 'bait'.  As a non-privileged
> user, I created a firmlink in /tmp to /root/baitdir and rebooted.  Voila!
> 'bait' vanished.
> 
> I took the time to read some of this mailing list's archive on the
> subject.  The consensus seems to be that you can't trust unprivileged
> translators.  So "find", which is used to clean /tmp, should not, in this
> case, cross translator boundaries.

I don't know which threads you have read exactly; but there have been
pretty conclusive discussions on this issue IMHO.

The "quickfix" solution is simply by default not to follow translators
running with a different UID than the client. (Unless the translator is
running as root.) That's pretty much what FUSE does on Linux.

A more ambitious solution I came up with Carl is to change the reauth
mechanism: when crossing translator boundaries during a lookup, instead
of obtaining an new auth token associated with all of the IDs available
to the client process, we would create an auth token associated with
only the intersection of the IDs from the previous auth token, and the
IDs available to the new translator we are entering. This way, when for
example a root process follows a firmlink run by an ordinary user, it
would get an auth token associated with only that user's IDs, not the
root IDs; and when the firmlink redirects to some other FS location, the
following lookup would still be limited to that user's IDs -- so the FD
obtained from the lookup could not be used to delete a file that the
untrusted user has no permissions for.

> I was thinking at first that we should have something like the "-xdev"
> switch; "-xtrans", maybe?

Selecting how to treat translators in general is another long-standing
issue, but with a broader and somewhat different scope than the trust
issue. Backups are a pretty illustrative standard example for that.

The fundamental problem with this is that translators range from things
that behave and should be treated like traditional filesystem mounts, to
others that should be pretty much transparent -- trying to treat all of
them in the same manner is bound to create problems in one situation or
the other. We need a more fine-grained solution.

Trying to add options to handle all the possible cases to all relevant
client programs is not realistic. Thus the solution I advocate instead
is something I refer to as "namespace-based translator selection": the
user adds special suffixes to paths, which are transparent to the
clients doing the lookup, but invoke special handling in the lookup
mechanism. Thus for example "rm -r /foo,,*" would follow all
translators, while "rm -r /foo,,0" wouldn't follow any; yet other
options could be more selective, following only certain classes of
translators etc.

Many years ago Sergiu worked on a prototype implementation we called
"nsmux" (for lack of a more suitable name) in the context of a GSoC
project (kinda), and we got many in-depth discussion along with a
partially working implementation. It didn't get finished, because the
implementation as a proxy server turned out more involved than initially
anticipated (the other option would be implementing it in glibc); and
also because I wasn't able to keep up with the amount of mentoring
necessary I think... But the idea is still out there.

(My favourite feature of this mechanism is the ability to specify
"dynamic" translators to be applied during the lookup, without a need to
explicitly set them up first; so we could for example do something like
"vi /foo/bar.gz,,unzip" -- I believe this would really give the Hurd an
edge in convenience over other systems...)

> Yet since filesystem mounts are themselves done with translators, what does
> "-xdev" mean on Hurd?  I've poked around a bit in the source, and played
> with 'stat'.  It seems like several translators take an arbitrary number
> and present it as their device number.  Seems like legacy support, and it's
> easy for a translator to defeat -xdev by announcing the same device as its
> parent.

This is actually an interesting idea for a partial solution: we could
introduce some mechanism that would allow specifying (e.g. as an option
to settrans) whether a translator should be transparent or mount-like;
which would determine whether the translator is allowed to claim the
same device ID as its parent or not. That would require some major
interface changes in the Hurd -- but it might be worth the effort.

> On a related note, how do you find the owner of a passive translator?  I
> expected either showtrans or ls to 

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Olaf Buddenhagen]

Hi,

On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun  wrote:

[...]
> > The solution, whatever it is, should focus only on determining whether
> > a server can be trusted or not. This should affect everything (servers,
> > (active) translators and translator records).
>
> Yes, we need to clearly determine when a server is trusted.
[...]

Actually, a generic notion of a server being "trusted" is a much more
complex problem. We discussed several options with Carl in the context
of his work on "object migration", which required determining when it's
safe to execute server code with the authority of the client. IIRC we
didn't come up with a conclusive approach...

However, trusting lookups is a way more specific problem, which we
believe we have a pretty good idea of how it can be addressed.

-antrik-

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

[Olaf Buddenhagen]

Hi,

On Wed, Aug 31, 2016 at 02:16:12PM +0200, Samuel Thibault wrote:

> Linux' notion of nice values is already not
> really POSIX for root :) (POSIX doesn't define negative nice values).

It's been a while; but I'm almost confident that according to my last
reading of the POSIX man pages, the Linux implementation is actually
perfectly correct -- the POSIX description is just very confusing...

Note that this is a very old known issue, and there was previous
discussion. (Which I'm too lazy to try digging up...) My conclusion was
that trying to implement it correctly on top of the existing Mach
interfaces would be tricky, for no real benefit -- we should just change
the kernel interface instead to directly provide the semantics needed
for POSIX behaviour.

-antrik-

Proxy memory objects (was: Denial of service attack via libpager)

[Olaf Buddenhagen]

Hi,

On Mon, Aug 29, 2016 at 11:15:48AM +0200, Richard Braun wrote:

> OK, this comes from the fact that io_map directly provides memory
> objects indeed... Do we actually want to pass them around ? How
> come calls like memory_object_init (specifically meant to be used
> between the kernel and the pager) can be made from any client ?
[...]
> If we consider Unix as a reference, then the map call uses a file
> descriptor. It's equivalent to a memory object because the translation
> is done privately in the kernel, but we could also change the
> mapping interface to provide some proxy object to the client,
> which could be thought of as an unprivileged memory object.
[...]
> The changes involved here are heavy, which is one reason we'd want
> to avoid them.

Note that we already have proxy memory objects is gnumach. (At least the
Debian variant -- don't know whether this ever went upstream.) It
currently only implements restrictions on write access (with Marcus'
original patch), and for offset/size (with my additions); but I suspect
it should be easy to also add restrictions on the management RPCs?

Note though that I never fully understood how the memory object
management protocol works and is used -- so no idea how that would
affect the Hurd as a whole...

-antrik-

Re: problems with a subhurd

[Olaf Buddenhagen]

Hi,

On Sun, Sep 04, 2016 at 12:34:09PM +0200, Justus Winter wrote:

> I recommend against shutting down subhurds.

This is a regression, though -- I'm pretty sure I used `halt` and/or
`reboot` in subhurds in the past. (Sometimes it failed; but it never
broke my main instance IIRC...)

-antrik-

gnumach copyright assignment (was: [bug #49056] sending mach_port_kernel_object to non-task object crashes mach)

[Olaf Buddenhagen]

Hi,

On Sun, Sep 11, 2016 at 03:27:05PM +, Kalle Olavi Niemitalo wrote:

> If I understand
> https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant correctly,
> the FSF does not want more than around 15 lines of code without a copyright
> assignment.

The FSF doesn't actually require assignments for gnumach -- almost all
of gnumach is foreign code without FSF copyright anyway...

-antrik-

Re: RFC: Revised authentication protocol

[Olaf Buddenhagen]

Hi,

On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote:

> Here's my proposal for dealing with the authentication issue.
> 
> There should be an extra send right passed from the auth server, to the
> client, that the client then passes along to the server in its
> authentication request, and that the server then passes on to the auth
> server in its auth_server_authenticate messsage.  This is distinct from the
> auth_object.  Unlike the auth_object, this right conveys no credentials and
> is used primarily to identify the auth server.  Let's call it the
> auth_identifier.
> 
> In the present scheme, you can see that the auth_identifier gets passed
> around in a big circle.  When the auth server gets the
> auth_server_authenticate message from the server, it sees that it's gotten
> its own auth_identifier back, and things proceed as they do now.
> 
> The more interesting case is when the auth_identifier differs.  That
> happens when we're dealing with two different auth servers on different
> hosts.
> 
> First, the auth_identifier allows the auth server to detect this case.
> 
> Next, it provides a means for the two auth servers to complete the
> rendezvous.  The server's auth server can pass the rendezvous right to the
> client's auth server using the auth_identifier.
> 
> There's no way for the server's auth server to fool the client's auth
> server into thinking that this is a normal server authentication request,
> because the only communication between the two is via the auth_identifier.
> The client's auth server can clearly distinguish messages coming in over
> this port from auth_server_authenticate messages, which would come directly
> from a server over a different port.
> 
> Finally, the auth servers can use the auth_identifier to speak any kind of
> inter-auth-server protocol that they wish.  At the moment, the exact
> details of that protocol are beyond the scope of this proposal.  I
> envision, perhaps, a public key exchange.  Something that would let
> mutually cooperating auth servers decide how to map UIDs/GIDs from one auth
> domain to another.  I haven't thought through the details, but I think this
> proposal is flexible enough to handle just about anything we'd want to do.

I'm a bit confused here: my understanding was that you essentially
wanted to implement a "single system instance" cluster. I would have
thought that would imply only a single instance of most servers --
including auth -- rather than separate ones for each node?...

Note that for the container solutions (lightweight virtualisation) I'm
envisioning for the Hurd -- with things like sub-users -- we are likely
to need some kind of auth delegation scheme or something like that; but
I haven't spent too much thought on this. Not sure whether it would be
relevant to your work in any way...

On Mon, Sep 05, 2016 at 02:09:56PM +0200, Richard Braun wrote:

> I'm not completely familiar with the inner workings of the auth
> server but they look easy enough to imagine. Still, an opinion
> from someone more familiar with it like Olaf would be great.

I'm not really very familiar with the details of the auth protocol. The
stuff I discussed extensively with Carl at some point (as a solution to
the infamous "firmlink issue") was more about handling of the ID sets
obtained through the auth mechanism -- I don't think it involved changes
to the auth protocol itself... Not sure though. Maybe Carl remembers
better than me?

-antrik-

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Olaf Buddenhagen]

Hi,

On Sun, Aug 07, 2016 at 09:13:55PM +0200, Richard Braun wrote:
> On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote:

> > settrans -ck /servers/socket/1 /hurd/pflocal
> 
> I suggest you don't do that, since you'll basically replace the pflocal
> instance for all the system, which might break already running
> processes.

Well -- assuming we auto-corrected this command in our minds to
"settrans -ak /servers/socket/1 /home/something/pflocal" -- it would
only affect running processes if the open new sockets, which doesn't
sound too terrible for testing... Though I'd probably still rather do
this in a subhurd :-)

-antrik-

Kernel debugging / drivers (was: USB keyboard driver the GNU Mach)

[Olaf Buddenhagen]

Hi,

On Mon, Feb 29, 2016 at 12:41:43PM +0100, Justus Winter wrote:

> While we generally want to move away from drivers in the kernel, it
> might indeed be nice to have a keyboard driver inside it for kdb.

Hm, this is an interesting point. I haven't actually considered keyboard
drivers up till now; but there is an even bigger problem: as soon as you
are no longer running VGA text mode, kdb won't work without huge amounts
of graphics driver code in the kernel.

In the end, it seems we have to give up on the idea of kdb using
in-kernel console drivers. That doesn't mean we have to give up on a
kernel debugger though: we could load a self-contained, separate OS
alongside gnumach, which remains inactive until kdb (or the panic
handler) is invoked.

-antrik-

Re: Porting Mach syscall/ipc to Linux

[Olaf Buddenhagen]

Hi,

On Fri, Jan 15, 2016 at 09:52:54AM +0100, Luca Dariz wrote:

> has anyone already tried to port or implement the Mach syscalls and ipc
> to Linux?

Someone on IRC mentioned a project recent-ish that apparently works on
implementing some Mach interfaces in Linux, to allow running certain
system services from Darwin (launchd etc.).

While gnumach and Xnu have somewhat diverged, the basic mechanisms are
pretty much the same -- so it shouldn't be too hard to adapt it for Hurd
usage as well I guess...

-antrik-

Re: licensing of intloop() in libddekit/interrupt.c

[Olaf Buddenhagen]

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?

-antrik-

Re: licensing of intloop() in libddekit/interrupt.c

[Olaf Buddenhagen]

Hi,

> 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?

While we haven't heard from him in years, I was able to dig something up
that seems current: http://www.cs.jhu.edu/~zhengda/

The linked GitHub account ( https://github.com/icoming ) has an (empty)
subhurd repository -- so it's definitely the right guy :-) There is an
address there: dzhe...@jhu.edu

There is pretty recent activity; so it should be up to date I hope.

> > In case he can't be reached anymore, I traced origin of the
> > intloop() routine
[...]
> > With this we have "Copyright (C) 2009, 2010 Zheng Da", but still no
> > licensing information.

If you are resonably sure that the code in question was indeed added by
him, not imported, then maybe we don't even need to contact him: he
signed a copyright assignment for the Hurd of course, and I assume it
applies to this code as well -- so the copyright holder is actually the
FSF.

> > Unfortunately this gets a bit confusing: some parts of the Hurd are
> > GPLv2 and some are GPLv2+.

It should all be v2+, except for bits imported from Linux and/or DDE.

> > Then the file Zheng was modifying [1] is imported from DDE/L4 which
> > is GPLv2 [2].
[...]
> > 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.

By default we can assume that the added code carries the same licensing
terms as the rest of the file, i.e. GPLv2 only. There certainly should
be no problem getting permission from the FSF to distribute it under v2+
terms; and considering it's nothing strategic, I'm pretty sure we could
also get a permissive license, if we think this is preferable to match
the rest of librump...

(I don't know how the code fits together though -- it *might* be
preferable to actually put the Hurd interface part into a library in the
Hurd repository, which is what Antti suggested I think...)

-antrik-

Re: libusb+librump patch

[Olaf Buddenhagen]

Hi,

On Tue, Oct 20, 2015 at 02:22:21AM +, Antti Kantee wrote:
> On 19/10/15 10:26, Olaf Buddenhagen wrote:

> >Fault isolation is also a concern -- though not the primary goal of
> >the Hurd architecture.
> 
> What exactly are you trying to isolate faults from?  If the bottom or
> top layer of the USB stack fails, applications will still fail.  Ok,
> if the top layer has no PCI access, then maybe it can't misprogram the
> DMA controller. But that would be a malicious attack, as the chances
> of the top layer accidentally misprogramming DMA are astronomical.
> And then you're better off trusting an IOMMU.  So I'm not sure I'd put
> indirection along the normal path for that case.

No, it's not really about that -- I agree that accidental misprogramming
of unrelated hardware is a fairly unlikely scenario.

However, as we are working with an unsafe programming language here, all
kinds of basic programming bugs in *any* component can bring down the
entire stack. (And ofter open security exploits too.) Address space
(process) boundries tend to help a lot with isolating such problems.

For most microkernel systems, this is actually *the* single major
selling point. For the Hurd, it's not a primary goal -- but still a nice
bonus...

> >>For the USB protocol splitting, you could run one rump kernel
> >>instance so that it exports ugen, and another one which uses ugenhc
> >>and provides the high-level drivers.
> >
> >I suppose that's what you mentioned in an earlier discussion,
> >regarding use of libusb?...
> 
> No, libusb would run on top of the /dev/ugen provided by a rump
> kernel. That different from running two rump kernel instances on top
> of each other.

Yeah, but you mentioned at some point adding support for the
higher-level parts of the stack to use libusb as backend, so they could
run on top of another instance providing the lower-level functionality
via ugen? Or was that a misunderstanding?

> Well, for one, the ugen interface loses information over what is
> available for the USB stack running on top of a "native" host
> controller, so some of the bits in the ugenhc implementation are
> creative protocol-handling-by-heuristics.

Ouch. Is that a problem with the specific ugen protocol, or a
fundamental limitation of any generic HC driver interface?...

-antrik-

Re: libusb+librump patch

[Olaf Buddenhagen]

Hi,

On Sat, Oct 17, 2015 at 01:16:38PM +, Antti Kantee wrote:
> On 16/10/15 16:17, Olaf Buddenhagen wrote:

> Ok, so you'd decide how to limit the visibility and arbitrate bus
> access in your PCI backend

Yes, I believe that's the cleanest approach.

(Not sure whether there is actually consensus on that -- though I'd hope
so...)

> I guess splitting the stack, especially in the case of USB, would be
> possible, since the host controller is supposed to export "pipes" to
> the rest of the USB stack.  The next place you can split it is at the
> USB device protocol level, a la ugen.  And of top of that you really
> already have the actual devices.

I don't know enough about USB to have much of an opinion on that. I was
only thinking of a single level of splitting -- probably the ugen one...

> Not sure how much pluggability you would gain [...] meaning if you
> could use alternative implementations.

I don't expect to be using alternative implementations; but separation
of concerns can improve flexibility in other ways too...

Fault isolation is also a concern -- though not the primary goal of the
Hurd architecture.

> IIRC the pipes are specified in the USB standard, but I'm not sure if
> they're really standard.  Plus, you'd probably have to write some
> code, and I'm not sure that code would be upstreamable, so you might
> have to maintain it yourself too.

That's a strong hint not to go down this route ;-)

> For the USB protocol splitting, you could run one rump kernel instance
> so that it exports ugen, and another one which uses ugenhc and
> provides the high-level drivers.

I suppose that's what you mentioned in an earlier discussion, regarding
use of libusb?...

> Yea, I can see why it would be attractive for plugging into the
> intermediate protocol and providing the ability to translate it left
> and right.  However, I'm not sure it's a good approach if you want
> things to, you know, work.

Why?

> >However, Bruno (initially at least) doesn't actually want to do any
> >of this. Rather, for a starting point he wants to try for the
> >simplest possible architecture that somehow gives applications access
> >to USB devices (especially mass storage devices). So he is thinking
> >of something along the lines of what Robert did (giving mplayer
> >access to USB sound devices through librump) -- in the case of USB
> >mass storage, that would mean giving the filesystem servers access to
> >USB storage devices through librump. He doesn't seem to be very clear
> >on how that would work exactly, though...
> 
> The rump kernel would export the block device, and you'd access it
> from the fs server with rump_sys_read() and rump_sys_write().

Yeah, that sounds like what I would expect.

> Notably, rump kernels support remote system calls, so driving things
> remotely already works.  The keyword is "sysproxy".

That sounds quite interesting... Though it's already a step ahead of
what Bruno wants to do initially.

> If your fs server does the appropriate block level caching, that
> approach should be reasonably performant, too.

Let's pretend it does ;-)

-antrik-

Re: libusb+librump patch

[Olaf Buddenhagen]

Hi,

On Thu, Oct 15, 2015 at 01:28:24AM +, Antti Kantee wrote:

> So do you want to implement your own drivers on top of libusb and use
> the rump kernel only for the host controller and device-independent
> USB support, or do you want to actually use the USB device-level
> drivers too (mass storage, etc)?  Or both, depending on the device?
> Or something completely different?  I don't know what the Hurd mindset
> is!

Well, I'm not sure which parts of the discussion you have already seen,
and which were on the Hurd list only -- so let me try to rehash the
entire story.

Let's start with the *ideal* architecture we would like to have. There
should be a PCI server process, which presents device files for every
PCI device present; along with a libpciaccess backend which can be
pointed at any of these device files, giving access to the associated
hardware device(s) -- and only these. For each device we would run a
Rump instance in another server, in turn presenting a device file giving
access to the device functionality. In some cases -- such as USB --
these first-level drivers would ideally only give raw access; and for
things like USB mass storage for example, we would in turn run separate
driver instances on top of the raw device files, which would finally
present device files giving access to the logical functionality. (Such
as block device files for storage devices; audio device files for sound
cards; etc.)

Now fully implementing this architecture would be pretty ambitious
(especially the last part about separating raw drivers from logical
drivers, as Rump itself doesn't have such a separation yet AIUI?) -- so
we might take some shortcuts: for example letting the first level
drivers directly export the higher-level functionality too. Or possibly
handling multiple devices in a single server instance.

However, Bruno (initially at least) doesn't actually want to do any of
this. Rather, for a starting point he wants to try for the simplest
possible architecture that somehow gives applications access to USB
devices (especially mass storage devices). So he is thinking of
something along the lines of what Robert did (giving mplayer access to
USB sound devices through librump) -- in the case of USB mass storage,
that would mean giving the filesystem servers access to USB storage
devices through librump. He doesn't seem to be very clear on how that
would work exactly, though...

-antrik-

Re: A small change to gnumach.texi

[Olaf Buddenhagen]

Hi,

On Mon, Oct 12, 2015 at 01:03:37PM +0200, Samuel Thibault wrote:

> Thanks for the idea, I'm just wondering about the copyright and/or
> licence. We need to make sure that it is compatible with the GFDL used
> by the gnumach documentation.

Well, Thomas will know better than me -- but IIRC we put the entire wiki
under GFDL, precisely to allow for this kind of exchange?...

-antrik-

Meta: Three-phase patch review

[Olaf Buddenhagen]

Hi,

I just stumbled upon this, and it seems to me the Hurd project could
benefit from this approach:

   http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

-antrik-

Re: A small change to gnumach.texi

[Olaf Buddenhagen]

Hi,

On Fri, Oct 02, 2015 at 01:20:12PM -0400, Joshua Branson wrote:

> I've copied the history section of mach from the wiki into the
> gnumach/doc/mach.texi

Nice :-)

> My diff seems to be adding some changes that I did not intentionally
> make.

It looks like your editor automatically removed trailing whitespace in
several places...

While this is probably a good change per se, it is usually considered
bad practice to commit unrelated whitespace fixes in the same patch...
Would be nice if you could isolate it?

Also, please submit your .gitignore additions in a separate patch as
well.

Git (especially "git add") has various features that help with splitting
up changes into multiple commits :-)

-antrik-

Re: Shortest path to significant improvement in hardware support

[Olaf Buddenhagen]

Hi,

On Tue, Sep 29, 2015 at 06:31:01AM -0300, Bruno Félix Rezende Ribeiro wrote:

> From that perspective I'm looking for the most straightforward way to
> get hardware working on Hurd
[...]
> 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.

I don't think that's a viable approach for most use cases: it requires
all applications using any of the Rump drivers to run with full hardware
access. That's like MS DOS -- the exact opposite of a microkernel
architecture :-)

While theoretically there are ways to avoid that (see exokernel), that
would require considerably *more* changes than running Rump instances as
Hurd servers.

-antrik-

Re: A small patch for the Hurd Reference Manual

[Olaf Buddenhagen]

Hi,

On Fri, Sep 25, 2015 at 01:52:25PM -0400, Joshua Branson wrote:

> diff --git a/.gitignore b/.gitignore
> deleted file mode 100644

Not sure what happened to your .gitignore -- but you definitely don't
want this in the patch :-)

> +Note that it is impossible to share microkernel devices between
> +two running Hurds.  If you do not know what you are doing, this could
> +cause serious harm.  For example, two hurds with two filesystems
> +writing to the same partition will wreak havoc.  In the same way, two
> +hurds reading from the same terminal device will not share nicely.

It probably should be mentioned though that sharing *is* possible for
network devices. The different pfinet instances will just pick the
packets applying to them, based on IP.

There is also a "proper" user-space multiplexer for network devices now,
called eth-multiplexer. This is only needed though if you also want to
allow network traffic between the Hurd instances uning the device in
question, rather than just each of them communicating with other
machines.

> +When you're finished testing your new Hurd, then you can run the
> +@command{halt} or @command{reboot} programs to return control to the
> +parent Hurd.

I don't think this really belongs here?...

-antrik-

Device interfaces (was: USB Mass Storage with rump)

[Olaf Buddenhagen]

Hi,

On Thu, Sep 24, 2015 at 09:30:17AM +0200, Samuel Thibault wrote:
> Olaf Buddenhagen, le Thu 24 Sep 2015 00:11:26 +0200, a écrit :

> > As I already mentioned on IRC, I don't think we should emulate Mach
> > device nodes at all here. Rather, the USB mass storage server(s) would
> > export UNIX device nodes, which ext2fs/libstore can already deal with
> > AFAIK.
> 
> But the fs RPC interface is much more involved to implement than the
> device RPC interface.

Is it really? While I haven't implemented a trivfs translator doing
actual file I/O yet, they do seem simple enough to me... Or am I missing
something?

Also, it's a one-time effort. And it avoids the need to modify
libstore/storeio.

> Storeio already does the conversion nicely, why not reusing it?

Why introduce an unnecessary indirection, which makes things more
confusing and harder to use, if we can just use the standard Hurd I/O
interface directly?

The point of the store infrastructure is to abstract different backends,
so we are not bound to Mach devices only...

-antrik-

Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c

[Olaf Buddenhagen]

Hi,

On Thu, Sep 24, 2015 at 08:18:37PM +0200, Samuel Thibault wrote:

> It may still be impossible at the moment actually.  The
> SNDCTL_DSP_MAPINBUF and SNDCTL_DSP_MAPOUTBUF ioctls are precisely
> examples: they pass a struct which contains the address of a buffer.
> This can not be expressed with the current handling of ioctls in
> GNU/Hurd: the sound server can't read/write the client process memory.

AIUI, it is possible by adding explicit stubs for these specific ioctls
to our glibc. I think this is used both for ioctls with too many
parameters to encode them with the standard RPC ID mapping scheme, and
for ioctls with "problematic" parameters like these?

-antrik-

Re: USB Mass Storage with rump

[Olaf Buddenhagen]

Hi,

On Sat, Sep 19, 2015 at 11:57:03PM +0200, Robert Millan wrote:

> single Rump instance inside a single translator which exposes all of
> /dev in Rump namespace somewhere under host /dev hierarchy (e.g.
> /dev/rump/*).

This is certainly tempting, but also dangerous -- once a somewhat
working solution is in place, there is less motivation to do the "right"
thing...

Note that besides going fully monolithic (as described above), or fully
modular (as you suggested originally), a compromise solution that is
monolitic on the vertical axis (all layers in one server), but modular
on the horizontal one (seperate instance for each device) is also a
possibility. I'm not saying it's necessarily the best choice -- but it's
an option to consider. Ultimately it depends on how much effort the
person implementing it is willing to invest...

-antrik-

Re: USB Mass Storage with rump

[Olaf Buddenhagen]

Hi,

On Sat, Sep 19, 2015 at 10:52:13AM +0200, Robert Millan wrote:

> 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.

Quite frankly, I wouldn't either :-) It just sounded like Bruno wanted
to go with such a simplistic approach for the start...

> 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...

-antrik-

Re: USB Mass Storage with rump

[Olaf Buddenhagen]

Hi,

On Sat, Sep 19, 2015 at 10:59:39AM +0200, Samuel Thibault wrote:

> It'd probably be easy to make ext2fs open a device node, just like we
> made pfinet do it.

As I already mentioned on IRC, I don't think we should emulate Mach
device nodes at all here. Rather, the USB mass storage server(s) would
export UNIX device nodes, which ext2fs/libstore can already deal with
AFAIK.

-antrik-

Re: Sound translator / PCI device handling

[Olaf Buddenhagen]

Hi,

On Sat, Sep 19, 2015 at 01:24:17PM +, Antti Kantee wrote:

> IMO the right way to do device drivers in a hosted environment is to
> have one entity which decides which servers see which devices and just
> let the servers attach to all devices they see.

>From what I gathered from Robert's and your explanations, it sounds to
me like the PCI server we are envisioning would be perfectly in line
with this design. The PCI server would expose one UNIX device node for
each PCI device present; and the Hurd backend in libpciaccess would open
these nodes to access the config space bits of any particular device.

The device node(s) to use would probably be passed as command line
parameters to each Rump translator instance -- so it would only see the
devices explicitly specified. No need for any other configuration :-)

-antrik-

Re: Sound translator

[Olaf Buddenhagen]

Hi,

On Sat, Sep 19, 2015 at 10:52:01AM +0200, Robert Millan wrote:
> El 19/09/15 a les 01:06, Olaf Buddenhagen ha escrit:

> >Is there any actual logic that could be split out into the audio and
> >mixer translators?
[...]
> 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.

That's a bummer. I was assuming that all BSDs -- and by extension, Rump
-- use OSS...

> 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?

I guess whether it makes sense to split the translation for audio and
mixer devices depends on how this is factored in libossaudio...

-antrik-

Sound translator / PCI device handling (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

On Thu, Sep 17, 2015 at 09:55:32PM +0200, Robert Millan wrote:
> 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.

Same for DDE -- I guess that's just how kernel drivers tend to handle
device probing...

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..."

-antrik-

PCI device handling (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

On Fri, Sep 18, 2015 at 09:14:30PM +0200, Robert Millan wrote:
> 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 :

> >>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.

Note that the original purpose of libpciaccess was to get rid of
register poking in the X server, and use proper system-provided PCI
access methods instead.

The register poking backend was added after all (after some initial
reservations) for the sake of the Hurd, because we just don't *have* a
proper PCI access method yet... That's a kludge, though -- the plan
always has been to implement a proper PCI server in the Hurd at some
point, and then to provide a libpciaccess backend to access it.

Same for other systems using the register-poking backend.

-antrik-

USB Mass Storage with rump (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

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?

-antrik-

Sound translator (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

On Wed, Sep 16, 2015 at 10:12:19PM +, Diego Nieto Cid wrote:
> El mié., 16 sept. 2015 a las 17:57, Robert Millan () escribió:

> > 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).
[...]
> What comes to mind, is that a translator can serve a directory and the
> nodes inside it. The console does it, IIRC.
> Thus, you could put the sound translator on top of say /dev/sound-stack/
> which provides audio, mixer, etc nodes. And then link the standard
> locations to there.

That's what I wanted to propose as well. It's both simpler to implement,
and less obscure in use; and I don't see any obvious downsides...

-antrik-

Sound translator (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

On Thu, Sep 17, 2015 at 12:25:21PM -0300, Diego Nieto Cid wrote:

> Another alternative, I was considering while going back home from work, is
> to design this in layers. As in the following graph:
> 
> ++
> | Applications   |
> ++
> > read, write, ioctls...whatever is
> standard
> ++ ++
> | /dev/audio | | /dev/mixer | ...
> ++ ++
> > might be some custom protocol if
> required
> ++
> |driver translator   |
> ||
> | rump   |
> ++
> ++
> |hardware|
> ++
> 
> In that way there are several sound related translators separating the
> concerns while the hardwarde is still accessed by a single translator
> avoiding the conflicts Robert mentioned.

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...

-antrik-

Sound translator / PCI device handling (was: Full-time developer available)

[Olaf Buddenhagen]

Hi,

On Thu, Sep 17, 2015 at 05:35:28PM +0200, Samuel Thibault wrote:

> For me, the idea could be that you run a rump translator per PCI device,
> which exposes devices appropriately. We'd need a common PCI translator
> to multiplex accesses to the config space, but otherwise working on
> a PCI device can be separate (and even made safe by using VT-d when
> available!)

That would be the ideal (also for netdde BTW) -- but considering this
will be more complex both in terms of implementation and design
considerations, I'm somewhat ambivalent as to whether this should be
attempted for the first take...

-antrik-

Re: Question with moving mount/umount logic in glibc

[Olaf Buddenhagen]

Hi,

On Fri, Jul 10, 2015 at 12:37:04AM +0200, Ludovic Courtès wrote:
 Roland McGrath rol...@hack.frob.com skribis:

  Frankly I think it would be better to keep these single-caller
  interfaces out of libc proper.  It's not really ideal that they are
  there for Linux either, but syscall stubs are less of an issue than
  real code.
 
 While not ideal, I think it would greatly simplify porting to have
 libc provide those functions regardless of the kernel.

I think what Roland is trying to say here is that the mount(2) call is
not really intended as an API, but rather just a system-specific
low-level syscall wrapper existing solely for the convenience of the
system-specific mount(1) utility implementation; and other programs have
no business invoking it directly at all. (At least that's my
impression...)

Also, the semantics of translators have some subtle differences from
traditional mount points -- so I'm not sure it's really a good idea to
let applications believe they are dealing with the same mechanism...

Having said that, *if* it's actually common practice nowadays to
(mis)use the mount(2) call directly, I'd say it *might* indeed be more
convenient to implement a compatibility wrapper at the libc level...

-antrik-

Re: Virtualization and HURD, another GSoC idea

[Olaf Buddenhagen]

Hi,

 Back to the point, perhaps you know that new CPUs from Intel and AMD
 add support to virtualization in hardware, and work has been done to
 incorporate this support in the Linux kernel through the KVM project.
 My questions is, how feasible would be the idea to create something
 like that for the GNU/Hurd, should this support be added to the core
 kernel, or should it be supported by userspace applications (e.g
 through an emulator like QEMU).

While this is certainly also an interesting topic, and might be a good GSoC 
project, note that this is explicitely *not* what the project idea in the list 
is about...

-antrik-
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Re: Yet Another GSoC Project Ideas Post

[Olaf Buddenhagen]

Hi,

 1- procfs

 This sounds like a very interesting project and indeed it's the most
 interesting to me. However, I'm a newbie to the Linux kernel, and I am
 completely new to Hurd. I am quite passionate about the subject and I
 find it a good opportunity to improve my knowledge of both the Linux
 kernel and Hurd, but do you think this project would be doable within
 the summer period for someone with little experience?

That should be OK. You don't really need to know much about Linux for this 
task; and learing about Hurd programming is part of the idea of GSoC :-)

You need good general programming skills, of course...

 2- Driver Glue code

 The idea description is quite obvious, again the question here is
 again of experience. I have basic knowledge about Linux device
 drivers, do you think it'd be feasible to apply for this one?

Well, what is basic knowledge? You should already be familiar enough to have 
a rough idea what the glue layer needs to provide to use Linux drivers... Or 
learn very quickly :-)

 3- Sound support

 This is also a very interesting idea to me. And I already think about
 porting the AC'97 driver since it's very widespread. My question is
 about the sound server. I just wanted to know, whether the userspace
 server has to implement the ALSA/OSS API or should that be implemented
 in the kernel?

Well, as you will be porting ALSA or OSS drivers, it makes sense to more or 
less preserve the API at kernel level... What the server needs to do is 
translate UNIX device access (read/write, ioctl etc.) to Mach device calls -- 
should be pretty straightforward.

 Sorry if the question sounds stupid, please bear with
 my newbieness :P

No worries, your questions seem to show pretty good understanding :-)

 4- Porting Hurd Servers from Cthreads to Pthreads

 I have some experience working with Pthreads under GNU/Linux. But does
 the project require knowledge about the internals of Pthreads (i.e. Is
 the student supposed to work on the HURD pthreads implementation), or
 is it only required from the students to port to Pthreads directly?

If all goes well, you shouldn't need to hack the pthreads implementation. It 
*could* happen though that you encounter some shortcomings that need to be 
fixed to proceed...

-antrik-
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: Student for GSoC 2008 - procfs

[Olaf Buddenhagen]

Hi,

  Sorry all of you. I am extremely sorry for being so late in
 sending
 this mail.

You aren't late at all -- official application period is starting only on 
monday :-)

 I did go through few guides and tutorials on procfs
 on
 GNU/Linux system.
[...]
 Please give me some time to go through it fully since it is a pretty huge
 documentation and it takes some time to digest it.

It's very good that you already looked into all this stuff :-)

Note that it's not a problem if you don't know every detail of Linux procfs. 
Take a look into which parts of procfs are actually needed for tools like 
procfs, and concentrate on implementing that...

   I have a working Installation of the GNU system[Debian GNU/HURD K-16], I
 checked out the CVS code of procfs in the hurdextras repo. I also read the
 Documentation thats there in the CVS [...]
 I am also going through the code. I hope you people understand that
 going through the entire code and understanding in less than 5 days is
 quite
 difficult for beginners.

Of course -- you seem to have done quite a lot already :-) You will have enough 
time to understand the details. For now, having an idea how stuff works in 
general and what you need to change is a very good start :-)

 I think its bit difficult to port all the features in
 GNU/Linux procfs to HURD in 3 months by a single person, though its not
 impossible(I also think its not necessary to port each and every feature
 thats available in GNU/Linux).

Indeed, we don't need all features -- only what's needed for procfs, top and 
similar tools.

I think most important of all the features that are to be made
 available
 are proc/pid/* features which are very important to implement process
 related functionalities. So we need to focus on it at the moment.
 Those features include
 /proc/pid/cpu
 /proc/pid/cwd
 correcting the problems in /proc/pid/environ
 /proc/pid/mem
 completing /proc/pid/stat
 /proc/cmdline
 /proc/swaps

/proc/pid/mem is problematic. Do we really need it for procps etc?

I don't know enough about the others -- what they do, what they are needed for. 
Could you give a short summary, why you think each one important?

 (This is only a rough idea of what can be done. I will draw the plan after
 discussion here is complete. I am open for all your inputs. I will be
 available in #hurd at the time which is convinient to you all. Please
 inform
 me so I can make myself available at that time. Please help me.)

I will only be online again Wednesday evening. But most of the time, someone 
else should be on IRC -- just keep in mind that people sometimes need quite 
long before they can reply :-)

Most people are online during the day and evening in european timezones -- 
roughly 12:00 to 24:00 UTC or so...

All in all, what you wrote above sounds quite promising -- I'm sure you will be 
able to hand in a very good application :-)

-antrik-
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer