Re: Updating the hurd in Guix

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

Re: Updating the hurd in Guix

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.

Re: A deferred authorization-granting translator

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,

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

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

Re: kernel panic in gsync_wait

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

Re: gnumach copyright assignment

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

Re: Mach "pipe" between parent and child

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()

Holy war (was: libpager multi-client support)

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

Re: Fully loadable device drivers

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

Re: gnumach copyright assignment

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

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

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

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

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

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

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

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

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

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

Re: problems with a subhurd

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)

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

Re: RFC: Revised authentication protocol

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

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

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

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

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

Re: Porting Mach syscall/ipc to Linux

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

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

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

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

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:

Re: libusb+librump patch

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

Re: libusb+librump patch

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

Re: libusb+librump patch

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

Re: A small change to gnumach.texi

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

Meta: Three-phase patch review

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

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

Re: Shortest path to significant improvement in hardware support

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

Re: A small patch for the Hurd Reference Manual

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

Device interfaces (was: USB Mass Storage with rump)

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

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

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

Re: USB Mass Storage with rump

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

Re: USB Mass Storage with rump

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

Re: USB Mass Storage with rump

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)

Re: Sound translator / PCI device handling

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

Re: Sound translator

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 provi

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

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

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

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

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

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

Sound translator (was: Full-time developer available)

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

Sound translator (was: Full-time developer available)

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

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

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

Re: Question with moving mount/umount logic in glibc

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

Re: Virtualization and HURD, another GSoC idea

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

Re: Yet Another GSoC Project Ideas Post

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

Re: Student for GSoC 2008 - procfs

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