Hi,
looking at
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/src/drivers/block/ide.c
i get the impression that WAIT_WORSTCASE is for a single ATAPI
transaction. So a long delay loop would not necessarily be a case for
WAIT_WORSTCASE.
But my Pioneer BDR-S09 drive shows long dela
Hi,
Damien Zammit wrote:
> I didn't think anyone would consider waiting 30 seconds for a cdrom in 2022.
With real hardware and a poor relation between drive and medium i would
deem 10 seconds too short as an upper limit. Worst time measured by
libburn's SCSI logging was about 25 seconds. That was
Hi,
Paul Dufresne wrote:
> It seems possible (to boot from a CDROM in UEFI) with SysLinux:
> https://wiki.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
SYSLINUX is the bootloader which cannot boot via UEFI from optical media.
Its EFI code works from USB stick or hard disk, but not from DVD.
Hi,
> > Well, the overall question is: Is it worth an effort ?
> I guess it could. Then we wouldn't need to make /dev a tmpfs and
> create it's content on demand. Then again, doing so is easy enough
> (with the bootshell).
So this discussion was mainly for my curiosity.
If the need arises to im
Hi,
Justus Winter wrote:
> 3. Remaster using `grub-mkrescue --output=my-bootshell.iso /=master'.
The beauty of grub-mkrescue.
More people should use it and increase its weight in GRUB2.
Even in the simple BIOS case, it already hides these expert
options of xorriso:
--grub2-mbr ...disk.path..
Hi,
> http://darnassus.sceen.net/~teythoon/bootshell0129.iso.xz
Was it produced by grub-mkrescue ?
> * Boots an unmodified Debian (debootstrap --variant=minbase) from a
> readonly filesystem that does not support passive translators
> (iso9660fs).
Would that support be desirable and what pr
Hi,
> > (Is there a pun path from Old MacDonald's e-i-e-i-o to Hurd's EIEIO ?)
> There definitely is.
Maybe the message should just say:
"With a beep-beep here and a moo-moo there: EIEIO !"
A matching german theme would be our duckling song:
"Alle meine Entchen, schwimmen auf dem See.
Koepf
Hi,
> "Das Computer gab den Löffel ab" (The computer gave the spoon away)
For a better matching language level and correct gender it would be
"Der Computer hat den Löffel abgegeben."
> "Das Computer beißt ins Gras" (The computer eats the grass)
"Der Computer hat ins Gras gebissen."
Both Meta
Hi,
> Time to nag you again:)
I can stand that. :)
> I assume you are a GNU fan
I am a GNU maintainer. Not that this would involve much of
a carreer or promotion, but nevertheless i maintain GNU xorriso.
> How much effort is needed, do you think, to get CD/DVD/RW/RW
> capabilities for GNU/Hu
Hi,
[Sorry, a wrong option with the mail sender client ate up the
reply and subject headers. So once again hopefully in the right
mail thread:]
i wrote months ago:
> > I plan to revisit the CD-on-Hurd topic when i'm done with CD-TEXT.
> > I could still need a tutor then, who leads me through th
Hi,
i wrote months ago:
> > I plan to revisit the CD-on-Hurd topic when i'm done with CD-TEXT.
> > I could still need a tutor then, who leads me through the development
> > cycle of Hurd,
Svante Signell wrote:
> Are you finished with the CD-TEXT stuff by now? More hands would be
> appreciated. I
Hi,
> Don't you have any time any longer for working on this? I/we understand
> if you don't, but no reply since October 17 makes one wonder.
Well, actually i was waiting for a decision what RPC layout to use.
Meanwhile i explored the opportunities to operate a real CD drive from
a qemu guest. W
Hi,
about registering the new call in struct device_emulation_ops:
me:
> > I would see this as further cementing a bad tradition.
Olaf Buddenhagen:
> I'm not really set on this; but to me it looks like a new path for
> directly invoking driver-specific functions would just be taking an
> unnecess
Hi,
Samuel Thibault:
> I'm afraid I just can't afford spending time on taking part of the
> details. I see that you are understanding each other, so it should be
> fine.
So i present my current sketch mainly to Olaf for review and
hopefully for intermediate approval.
This proposal shall cover RP
Hi,
> Well, the problem is that if we decide on a solution you don't like, you
> won't be very motivated to follow it :-) That's why I'd prefer a
> solution in consensus between all involved parties, i.e. You, Samuel,
> and me.
In general, this mindfulness is surely helpful to gain co-workers.
Bu
Hi,
> > can anybody remember to have used a SCSI CD-ROM with Hurd ?
> I have just pushed a driver which should permit it.
So it will be possible to test the command transport via an SCSI
controller when there is a RPC to reach the transaction calls
in gnumach.
> Unfortunately, when enabling a
Hi,
Olaf Buddenhagen wrote:
> I could try to reach a consensus with Samuel, and present it to you as a
> fixed decision
In the end it will happen that way.
After all it is you who have the overall interest in Hurd, whereas
i am mainly striving for getting GNU xorriso work on GNU/Hurd with
simil
Hi,
it looks like we need two fundamental decisions now, or else the
contraints become too fuzzy for developing the desired feature:
1: Shall the new call be implemented on the kernel side as a
new method of struct device_emulation_ops ?
2: Shall the parameters be bundled in serialized struct
Hi,
i began to sketch serialization from struct to byte array.
Important question:
Am i allowed to make the RPC ugly if it reduces system load ?
There seems to be an inavoidable performance penalty with my naive
idea to allow an arbitrary reversible transformation from struct
to byte array.
In
Hi,
Olaf Buddenhagen:
> Unless there is some practical difficulty, I *strongly* suggest to
> describe the individual struct members with MIG, rather than doing the
> marshalling (serialisation) by hand.
Regrettably MIG explicitely refuses to model struct entrails.
mig.ps page 3:
"There is no way
Hi,
Thomas Schwinge wrote
> I was thinking about dmesg messages for SCSI; which device driver(s) does
> the Linux kernel use (dmesg)
Thanks to Svante Signell for reproducing my troubles.
> 00:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a
I see in the dmesg of RIP Linux
Adap
Hi,
> For example, you could boot a GNU/Linux system, and figure out which SCSI
> devices exactly are provided.
I did. RIPLinux-9.3-non-X.iso as emulated IDE CD-ROM boots with
64 bit kernel. An additionally emulated SCSI CD-ROM
-drive file=/dvdbuffer/netinst.iso,if=scsi,bus=4,unit=0,media=cdrom
Hi,
Thomas Schwinge:
> Unfortunately, i have not yet found the time to read the messages in your
> other thread. So, I hope I'm answering the correct questions here, being
> a bit out of context.
This new thread is about the newbie user problem to set up
what i want to test on the long term.
I a
Hi,
can anybody remember to have used a SCSI CD-ROM with Hurd ?
I tried to get access to a virtual one created with kvm:
-drive file=/dvdbuffer/netinst.iso,if=scsi,bus=4,unit=0,media=cdrom
but after booting Hurd, there is no /dev/sr0.
gnumach/linux/src/include/linux/major.h has
#define SCSI_
Hi,
me:
> > routine device_transact_native(
Samuel Thibault:
> Why "native"?
Because the transactions are of a genuine kind that is specified only
for particular device types.
I dug deeper in the existing code. It seems that my desired transaction
applies only to these storage device types:
-
Hi,
i had to learn that a kvm emulated CD-ROM appears as /dev/hd2.
I suspect this means it is not controlled by an SCSI driver but by
gnumach/linux/src/drivers/block/ide.c
gnumach/linux/src/drivers/block/ide-cd.c
Is this correct ?
If so then i will try to use ATAPI commands. E.g via
int
Hi,
Please ignore this sentence in my previous mail:
> Where was this assigned to mach_port_array_t resp. to init_port_set ?
It is a residue from obsoleted reasoning. I first found "^ array[]"
in gnumach/include/mach/mach.defs but later noticed that
device_set_status() itself has a variable leng
Hi,
current state of MIG definition (stop me when i go astray):
routine device_transact_native(
device : device_t;
infunction_code : unsigned int;
inin_data : ^ array[] of unsigned char;
out out_data: ^ array[] of unsigned c
Hi,
> http://www.gnu.org/software/hurd/microkernel/mach/mig/documentation.html
Actually it is the link labeld "ps" on that page which delivers
a description of the language:
http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps
My oldish gv has problems with page navigation in
Hi,
i believe to have found the connection between device_t in
userspace and Scsi_Device in kernel:
device_t arrives in device_set_status() of gnumach/linux/dev/glue/block.c
as (void *) and gets casted to (struct block_data *).
This struct has an element
kdev_t dev; /* Linux device number */
Hi,
> It's actually very simple to define an RPC, it essentially looks
> like a C function declaration, see ./include/device/device.defs
> for the device_set_status RPC declaration for instance.
Ahum ... i will have to design such a prototype.
> routine device_set_status(
> devic
Hi,
although still being heavily asynchronous with Olaf's mails:
me:
> > But looks quite out of my personal reach for now.
Olaf Buddenhagen:
> It should be much easier to implement than the five-step thing described
> above... The biggest difficulty is probably finding the various places
> where
Hi,
Samuel Thibault wrote:
> git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git
I failed to get the code that way. On my workstation and on the Debian
GNU/Linux host i experience:
$ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git
Cloning into gnumach...
The authenticity of h
rday (06 Sep 2011 18:32:55 +0200) are obviously already
answered in an older mail:
==
Date: Fri, 13 May 2011 22:42:09 +0200
From: Samuel Thibault
======
Thomas Schmitt, le Mon 09 May 2011 12:
Hi,
me:
> > [...] my favorite candidate among the files in my CVS copy.
Samuel Thibault:
> CVS Copy? The CVS repository is outdated. Which documentation advised
> you to check it out?
I have to guess a bit. But it looks like
http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Helpi
Hi,
Samuel Thibault wrote:
> AIUI it's device_get_status() in linux/dev/glue/block.c for the linux
> IDE & SCSI devices.
Yeah. That is my favorite candidate among the files in my CVS copy.
But i was uncertain to which side of the RPC gap this belongs,
because i could not spot a function device_ge
Hi,
me:
> > Will a 3 GB "disk" suffice ? Shall i install Hurd to a larger one ?
Jeremie Koenig wrote:
> I'd recommend using a larger image
> As a data point, one of my VMs has a 20 GB "disk" and I'm still running
> into disk space problems occasionally
olafbuddenha...@gmx.net wrote:
> Well,
Hi,
Svante Signell wrote:
> see http://www.gnu.org/software/hurd/community/gsoc/project_ideas/xattr.html
Ahum. I implemented xattr as extension of ISO 9660 + Rock Ridge
but know few about ext2 internals. So for now i will give it a rest.
If xattr and ACL cannot be used in the filesystem, then xor
Hi,
my second try ot install of GNU/Hurd on kvm obviously succeeded. :))
I am able to download and build GNU xorriso-1.1.5.tar.gz (without
CD drive capabilities).
So far so good.
Now i face the task of modifying both sides of the RPC gap, in order
to get a transport for SCSI commands and their r
Hi,
i wrote:
> > Does that mean i shall just try again with a new "disk" ?
Samuel Thibault wrote:
> Yes.
Ok. I am getting a new netinst.iso now and plan to retry in the next
days.
> > Is there a way to mount the partitions of the "disk" in Linux,
> > so i could read that grub.cfg ?
Svante Sign
Hi,
Samuel Thibault wrote:
> Ah, that's a known bug with GRUB which has been fixed since then.
Does that mean i shall just try again with a new "disk" ?
Or shall i get a new
http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/netinst.iso
first ?
--
Hi,
I Samuel Thibault's thread 'cdrom interface?' i wrote:
> > Well, i am a bit embarassed that i failed to get Debian/Hurd running
> > on qemu-kvm of a Debian/Linux squeeze. It installs but then does not
> > boot. Other things kept me from re-trying and then asking for help.
Samuel Thibault wrot
Hi,
Samuel Thibault:
> > There are quite a few packages out there which depend on the cdrom
> > interface. I'm wondering whether we could just provide the linuxish
> > interface for it in e.g. sys/cdrom.h. Most of the ioctls should
> > be working fine, only the data read ones would only work with
Hi,
olafbuddenha...@gmx.net wrote:
> you still need a way to access the actual burner... I don't
> really know, but I rather doubt that any VM solution actually exposes
> the host system's burner to the guest system as an ATAPI device
> connected to a virtual PATA controller...
libburn does not t
Hi,
me:
> A potential problem is that scsi_ioctl_send_command() is restricted
> to transfer MAX_BUF = PAGE_SIZE payload bytes.
Samuel Thibault:
> Page size on i386 is 4KiB.
> > I am unable to determine whether this limit also applies to scsi_do_cmd()
> > in hurd/gnumach/linux/src/drivers/scsi/sc
Hi,
Thanks to all for your patience with my newbieness.
me:
> > So it looks as if we have to stop here until a better skilled person
> > appears who is interested in enabling burner drive operation.
Samuel Thibault:
> I'll let it to anybody who has time for this.
After pondering and code reading
Hi,
> There's the "Documentation" link on this page which I believe has all
> the links that exist.
I meanwhile downloaded machuse.ps which drives my gv to the
edge of madness. It starts at page 20 and i can only go
backwards page by page. Probably i should make 20 screenshots
for reading them in
Hi,
(Shall i stop CC'ing help-hurd ?)
> > So i would rather propose a new function with the semantics of SG_IO:
>
> A completely hurdish interface for this would probably be the best, yes.
> You'll have to learn mig, however :)
Well, the SG_IO-ish wrapper around scsi_do_cmd() would be a matter
Hi,
> That interface isn't complete: the GNU Mach kernel uses linux drivers
> internally, and the scsi_ioctl() function is available there (thus with
> the linuxish interface), but its features have not been propagated to
> the device_get/set_status() user interface yet.
I see.
Googling "hurd de
49 matches
Mail list logo
