Applied, thanks!
We now need to add support in sd* node creation etc. just like is
already done with wd*.
Samuel
Damien Zammit, le lun. 03 juil. 2023 10:18:22 +, a ecrit:
> This adds a second binary target to compile in
> the rump USB stack instead of SATA/IDE using conditional
>
This adds a second binary target to compile in
the rump USB stack instead of SATA/IDE using conditional
ifdefs to mostly share the code between the two translators.
This can be tested by running qemu with a USB3 controller as follows:
-drive if=none,id=usbstick,format=raw,file=/path/to
Hello,
Damien Zammit, le mer. 28 juin 2023 10:52:10 +, a ecrit:
> diff --git a/rumpdisk/Makefile b/rumpdisk/Makefile
> index b59aaf9a..ab763570 100644
> --- a/rumpdisk/Makefile
> +++ b/rumpdisk/Makefile
> @@ -15,7 +15,9 @@
Nice, thanks for the factorization!
> HURDLIBS = machdev ports trivf
This adds a second binary target to compile in
the rump USB stack instead of SATA/IDE using conditional
ifdefs to mostly share the code between the two translators.
This can be tested by running qemu with a USB3 controller as follows:
-drive if=none,id=usbstick,format=raw,file=/path/to
Damien Zammit, le mar. 27 juin 2023 09:24:54 +, a ecrit:
> On 26/6/23 02:41, Samuel Thibault wrote:
> > We also need /dev entries. It happens that this re-uses /dev/sd*
> > names, so we need to care about compatibility. We probably want
> > rumpdisk_device_open to forward to the kernel when 'di
Hello,
Damien Zammit, le mar. 27 juin 2023 11:11:09 +, a ecrit:
> This is mostly a copy of rumpdisk,
It should be possible to share the code, by setting makemode to servers,
and using -D / #ifdef?
> with small tweaks to
> compile in the rump USB stack instead of SATA/IDE.
>
&
This is mostly a copy of rumpdisk, with small tweaks to
compile in the rump USB stack instead of SATA/IDE.
This can be tested by running qemu with a USB3 controller as follows:
-drive if=none,id=usbstick,format=raw,file=/path/to/disk.img \
-device qemu-xhci
Hi,
On 26/6/23 02:41, Samuel Thibault wrote:
> We also need /dev entries. It happens that this re-uses /dev/sd*
> names, so we need to care about compatibility. We probably want
> rumpdisk_device_open to forward to the kernel when 'disabled' is true.
Doesn't libmachdev do this for us already?
re.
El lunes 26 de junio de 2023, Damien Zammit escribió:
> Hi Samuel,
>
> On 26/6/23 02:41, Samuel Thibault wrote:
> >> This simple change allows hurd to be bootable off usb!
> >
> > Well, yes and no :)
> >
> > We also need /dev entries. It happens
Hi Samuel,
On 26/6/23 02:41, Samuel Thibault wrote:
>> This simple change allows hurd to be bootable off usb!
>
> Well, yes and no :)
>
> We also need /dev entries. It happens that this re-uses /dev/sd*
> names, so we need to care about compatibility. We probably want
>
Damien Zammit, le dim. 25 juin 2023 12:35:51 +, a ecrit:
> This simple change allows hurd to be bootable off usb!
Well, yes and no :)
We also need /dev entries. It happens that this re-uses /dev/sd*
names, so we need to care about compatibility. We probably want
rumpdisk_device_open
On June 25, 2023 2:35:51 PM GMT+02:00, Damien Zammit
wrote:
>This simple change allows hurd to be bootable off usb!
A running hurd can then recognize a usb storage
>
>It is not ideal to have entire usb stack with the mass storage driver
>and combined with SATA, but there is no
This simple change allows hurd to be bootable off usb!
It is not ideal to have entire usb stack with the mass storage driver
and combined with SATA, but there is no easy way to separate
the usb stack into host/device yet. This centralises all the disk
support, (and unfortunately also all the usb
Damien Zammit, le dim. 21 août 2022 07:02:26 +, a ecrit:
> This allows DMA in rump kernel usb drivers,
> stops an assert() crashing the rump kernel.
Applied, thanks!
>
> ---
> debian/rules | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/deb
This allows DMA in rump kernel usb drivers,
stops an assert() crashing the rump kernel.
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 3f2b637ad..2c8fc0648 100755
--- a/debian/rules
+++ b/debian/rules
@@ -40,7 +40,7
Paul Dufresne, le ven. 05 févr. 2021 17:50:32 -0500, a ecrit:
> Le ven., 05 févr. 2021 14:27:15 -0500 Samuel Thibault
> écrit
>
> > Paul Dufresne, le ven. 05 févr. 2021 12:22:33 -0500, a ecrit:
> > > Well, realizing that I would need to make a local mirror of Debian (to
> be
> >
Le ven., 05 févr. 2021 14:27:15 -0500 Samuel Thibault
écrit
> Paul Dufresne, le ven. 05 févr. 2021 12:22:33 -0500, a ecrit:
> > Well, realizing that I would need to make a local mirror of Debian (to be
> > edited by debian-cd, what a strange idea!)
>
> What do you mean by "ed
Paul Dufresne, le ven. 05 févr. 2021 12:22:33 -0500, a ecrit:
> Well, realizing that I would need to make a local mirror of Debian (to be
> edited by debian-cd, what a strange idea!)
What do you mean by "edited" ?
debian-cd picks up the .deb files from the mirror, that are needed to
have an insta
Samuel Thibault, le ven. 05 févr. 2021 20:03:02 +0100, a ecrit:
> > That's a bit weird for people, because it did read the files from the USB
> > key
> > up to the installer searching packages...
>
> Another way would be to just include all required d-i packages i
Paul Dufresne, le ven. 05 févr. 2021 12:22:33 -0500, a ecrit:
> Because Debian Hurd have no support for USB yet. So it cannot read the files.
Yes, and I believe that's what we should really fix, and currently being
fixed by the rumpdisk translator.
Departing from the current way d-i
(the iso
file...)on an USB key, then boot it.
But if you try that with current Hurd, you will realize that the installer will
not find the files...
Because Debian Hurd have no support for USB yet. So it cannot read the files.
That's a bit weird for people, because it did read the files fro
I can only assume that most Hurd developers would appreciate your work
in this. Please note, that in order for your code to be merged into the
Hurd properly, you would need to assign copyright to the FSF.
Would you be willing to do this?
--
Joshua Branson
Sent from Emacs and Gnus
I did some work a couple of years ago to add USB support to the Hurd. I
was successful in getting USB keyboard working. I anyone is interested
in continuing this effort, I would glad to turn over the work that I
have done.
*Rowland E. Smith*
+1-201-396-3842
On 5/28/20 8:59 PM, Joshua Branson
No. The Hurd does not support USB yet.
--
Joshua Branson
Sent from Emacs and Gnus
Hi all,
does HURD see USB keys ? I need to transfer a file to a system and I
have no network
I fear not, in dmesg I see hd0 hard disk, hd2 cdrom
no scsi hosts and I think USB is always through SCSI.
I tried running fdisk on /dev/sd0 and there is nothing
Riccardo
Hello,
I agree that having a in-kernel USB keyboard driver makes sense for the
debugger.
As for the interaction with userland USB support, I don't think we can
share the access to the same USB chip, so when the kernel driver is
running the userland driver can't run. One could say tha
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 no
f getting the hurd running on an
> oldish PC on bare metal. The first issue I encountered is that the PC does
> not have a PS/2 port and the BIOS does not seem of offer any emulation. GNU
> Mach does have any support for usb as far as I could tell.
>
> I have worked to re-purpose some
port and the BIOS does not seem of offer any emulation. GNU
Mach does have any support for usb as far as I could tell.
I have worked to re-purpose some old (2.4.x) Linux kernel usb code to
produce a basic usb keyboard driver for GNU Mach. It is a bit more than a
key board driver. It is a usb hardware
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
>
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) w
El 24/09/15 a les 00:05, Olaf Buddenhagen ha escrit:
Instead, you could run a Rump instance with USB mass storage only
which uses libusb as backend rather than its own *HCI driver (but that
requires some coding work as it's currently not implemented ;-))
Yeah, I guess that's the pr
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. Stor
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
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.
Qu
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 s
El 19/09/15 a les 10:59, Samuel Thibault ha escrit:
Instead, you could run a Rump instance with USB mass storage only which
uses libusb as backend rather than its own *HCI driver (but that requires
some coding work as it's currently not implemented ;-))
Indeed. We can however start with a
Robert Millan, le Sat 19 Sep 2015 10:52:13 +0200, a écrit :
> If you load *HCI support and USB mass storage into Rump, you can have
> /dev/XXX pop up in the Rump namespace and that will be your disk node.
> Then you can write a translator to link the host system into that disk
> (or
Olaf Buddenhagen, le Sat 19 Sep 2015 00:52:08 +0200, a écrit :
> 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?
I
El 19/09/15 a les 00:52, Olaf Buddenhagen ha escrit:
On Wed, Sep 16, 2015 at 10:57:20PM +0200, Robert Millan wrote:
El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
I'm interested in USB support. I'd like to aim mass storage devices at
first.
For USB using Rum
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
On Sunday 27 February 2011 19:25:56 Samuel Thibault wrote:
> Only in memory, no writeback is possible since grub doesn't live any
> more once gnumach is booted.
Damn, and I had hoped, I could at last use a real baremetal Hurd…
Well, seems I’ll still have to wait for real USB-suppo
Jakub Daniel, le Sun 27 Feb 2011 18:22:05 +, a écrit :
> Can I read/write from/to the root filesystem when I start Hurd from a USB
> stick?
>
>
> I would expect it to be possible to modify rootfs but only in case that it
> would be presented as ramfs which would no
Arne Babenhauserheide, le Sun 27 Feb 2011 19:12:57 +0100, a écrit :
> On Sunday 27 February 2011 18:40:00 Samuel Thibault wrote:
> > Err, I don't mean you can read/write a USB stick from GNU/Hurd, just
> > that grub can boot whatever it likes from a USB stick, thus GNU/H
>
> Can I read/write from/to the root filesystem when I start Hurd from a USB
> stick?
>
I would expect it to be possible to modify rootfs but only in case that it
would be presented as ramfs which would not hold information on the stick
(my uninformed point of view)
Oz, le Sun 27 Feb 2011 12:11:48 -0600, a écrit :
> Samuel can you please send me the link to the Hurd mini I got mad and
> deleted everything by accident.
It's on the Debian web site...
http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
Samuel
On Sunday 27 February 2011 18:40:00 Samuel Thibault wrote:
> Err, I don't mean you can read/write a USB stick from GNU/Hurd, just
> that grub can boot whatever it likes from a USB stick, thus GNU/Hurd
> among others. Actual filesystem access is another matter.
Can I read/write fr
Samuel can you please send me the link to the Hurd mini I got mad and
deleted everything by accident.
On Sun, Feb 27, 2011 at 11:41 AM, Samuel Thibault
wrote:
> Jakub Daniel, le Sun 27 Feb 2011 17:33:04 +, a écrit :
>> I also presumed that it wouldnt be possible as gnumach/hurd would not be
Jakub Daniel, le Sun 27 Feb 2011 17:33:04 +, a écrit :
> I also presumed that it wouldnt be possible as gnumach/hurd would not be able
> to access anything on the disk other than preloaded by grub which i supposed
> was vital for running hurd based os.
Yes, that's why in Debian we patched gnu
Arne Babenhauserheide, le Sun 27 Feb 2011 18:28:08 +0100, a écrit :
> On Sunday 27 February 2011 14:45:27 Samuel Thibault wrote:
> > > > dd < mini.iso > /dev/sda
> > >
> > > Does it boot from the USB key?
> >
> > It will, yes.
> >
I also presumed that it wouldnt be possible as gnumach/hurd would not be
able to access anything on the disk other than preloaded by grub which i
supposed was vital for running hurd based os.
On Sunday 27 February 2011 14:45:27 Samuel Thibault wrote:
> > > dd < mini.iso > /dev/sda
> >
> > Does it boot from the USB key?
>
> It will, yes.
>
> > I thought the Hurd were still missing USB support?
>
> But grub isn't, and that's what
Arne Babenhauserheide, le Sun 27 Feb 2011 14:36:54 +0100, a écrit :
> On Saturday 26 February 2011 13:15:10 Samuel Thibault wrote:
> > > i don't think copy and pasting the ISO in to the thumb drive (usb
> > > stick) will work.
> >
> > dd < mini.iso >
On Saturday 26 February 2011 13:15:10 Samuel Thibault wrote:
> > i don't think copy and pasting the ISO in to the thumb drive (usb
> > stick) will work.
>
> dd < mini.iso > /dev/sda
Does it boot from the USB key? I thought the Hurd were still missing USB
Jakub Daniel, le Sun 27 Feb 2011 09:41:58 +, a écrit :
> try using: dd if=PATH_TO_ISO.iso of=/dev/sdb1 #as root
not sdb1, sdb.
(and using if=/of= is almost the same as using )
Samuel
try using: dd if=PATH_TO_ISO.iso of=/dev/sdb1 #as root
root@icelogic-GA-870A-UD3:/home/icelogic# dd <
/home/icelogic/Downloads/mini-20110221.iso > /dev/sdb
0+0 records in
0+0 records out
0 bytes (0 B) copied, 6.2624e-05 s, 0.0 kB/s
lol now i get this and nothing copies :(
On Sat, Feb 26, 2011 at 6:49 PM, Samuel Thibault
wrote:
> Oz, le Sat 26 Feb 20
Oz, le Sat 26 Feb 2011 18:38:39 -0600, a écrit :
> icelogic@icelogic-GA-870A-UD3:~$ sudo dd <
> /home/icelogic/Downloads/mini-20110221.iso > /dev/sdb
> bash: /dev/sdb: Permission denied
>
>
>
> does anyone know how to fix this error?
Become root.
Samuel
icelogic@icelogic-GA-870A-UD3:~$ sudo dd <
/home/icelogic/Downloads/mini-20110221.iso > /dev/sdb
bash: /dev/sdb: Permission denied
does anyone know how to fix this error?
thanks in advance.
On Sat, Feb 26, 2011 at 1:15 PM, Samuel Thibault
wrote:
> Oz, le Fri 25 Feb 2011 23:02:09 -0600, a écrit :
>> Could you please tell me how to make a boot able usb image using your
>> mini iso samuel.
>>
>> i don't think copy and pasting the ISO in to the thum
Oz, le Fri 25 Feb 2011 23:02:09 -0600, a écrit :
> Could you please tell me how to make a boot able usb image using your
> mini iso samuel.
>
> i don't think copy and pasting the ISO in to the thumb drive (usb
> stick) will work.
dd < mini.iso > /dev/sda
Of course t
Could you please tell me how to make a boot able usb image using your
mini iso samuel.
i don't think copy and pasting the ISO in to the thumb drive (usb
stick) will work.
On Fri, Feb 25, 2011 at 9:25 PM, Samuel Thibault
wrote:
> Oz, le Fri 25 Feb 2011 21:18:31 -0600, a écrit :
>&g
[EMAIL PROTECTED] wrote:
> > If you port a driver you should take into account the license such
> > driver use. IMHO the Hurd should go towards full GPLv3 compatibility.
>
> Currently the drivers live in GNU Mach, which is a dependency of the
> actual Hurd, but otherwise they are quite disconnecte
Hi,
On Mon, Dec 01, 2008 at 12:41:08AM +0100, Davi Leal wrote:
> If you port a driver you should take into account the license such
> driver use. IMHO the Hurd should go towards full GPLv3 compatibility.
Currently the drivers live in GNU Mach, which is a dependency of the
actual Hurd, but other
Thomas Schwinge wrote:
> One thing to work on are device drivers. These would most probably be
> ported from another operating system (Linux, *BSD)
If you port a driver you should take into account the license such driver use.
IMHO the Hurd should go towards full GPLv3 compatibility.
The GPLv3
in this direction is in progress as of
> now. Any ideas, suggestions and guidelines will be very much helpful.
No work with respect to USB support is in progress as far as I know. A
lot of work will be needed to get this into a useful shape.
One thing to work on are device drivers. These wou
66 matches
Mail list logo
