IRC channel logs

<gnucode>well I'm trying to set up a subhurd. I've never actually done that before.

<gnucode>It's interesting that "dd if=/dev/zero of=my.image bs=1M count=1 seek=5000" fails.

<gnucode>I guess the Hurd's /dev/zero has some limitations?

<youpi>but large files (> 4G) have not really been tested

<youpi>so it's the output that fails, not the input

<gnucode>hmmm. so if someone wanted to fix "dd if=/dev/zero of=my.image bs=1M count=1 seek=5000" so that it works...what needs to be fixed?

<youpi>no idea

<youpi>possibly the whole thing

<youpi>possibly a small typo in ext2fs

<youpi>that just needs investigation

<gnucode>I do think that "boot /dev/hd0s6" is super cool. I wonder if multiple users can boot a subhurd from the same partition and just share the ext2fs filesystem. It seems like they should be able to do so.

<damo22>i dont think you can mount the same filesystem twice by different things that both write to it

<gnucode>I don't think I'm gonna be able to try a subhurd at the moment. I don't have internet access, and I'm having trouble creating my own image.

<gnucode>dd if=/dev/zero of=my.image bs=1M count=1 seek=2000

<gnucode>isn't working....or at least it's taking a long time.

<damo22>why seek?

<gnucode>that's the documentation that I found on the old wiki: https://darnassus.sceen.net/~hurd-web/hurd/subhurd/

<gnucode>nevermind that's the right wiki

<gnucode>and damo22 multiple Linux users share the same /home partition with different data.

<damo22>no, they have different directories

<damo22>/home/user1 /home/user2

<damo22>and only root mounts home

<gnucode>ok...you could have multiple different Hurd users invoking this..."boot ~/hurd.img".

<damo22>but with the hurd you can mount /home/user1 separate from /home/user2 and mounted by the user

<gnucode>in that case, they are likely using just 1 ext2fs

<youpi>depends what you call "use"

<youpi>you can't mount a filesystem several times at the same time

<youpi>but you can have several users store data on the same mounting of an ext2fs

<youpi>so several users can create their own hurd.img on their own home each

<gnucode>I guess that's what I meant. "you can have several users store data on the same mounting of an ext2fs"

<youpi>gnucode: that dd command is supposed to return immediately

<youpi>if you haven't rebooted since your try with 5000, ext2fs was probably not at ease with that, you should just reboot and fsck

<gnucode>ok. I'll reboot and double check.

<damo22>you cant have one copy of a disk image containing a filesystem and mount it multiple times inside two subhurds though

<youpi>yes

<gnucode>well I killed X. And the tty1 is not letting me input text. luckily I can switch consoles.

<gnucode>and I can't seem to login to tty2. :(

<gnucode>I sense a hard shutoff is imminent

<youpi>probably the same reason why the second dd was getting stuck

<gnucode>I am certain that filesystem corruption happens on the Hurd...but I have not really noticed any major corruption yet.

<gnucode>I edit the Hurd wiki all the time, have several hurd org files, my blog, etc. I've noticed no file system corruption on all of those text files.

<damo22>if you hard reboot without unmounting the filesystem you will get corruption on ext2

<damo22>which is why you need to fsck

<gnucode>damo22: I know. the automatic fsck fixed it most of the time for me. only 2-3 times have I had to manually run fsck

<damo22>youpi: there seems to be at least two ways to expose video info to gnumach, either the multiboot vbe tag or the multiboot framebuffer tag

<damo22>which one should we use?

<damo22>i suppose if we use vbe, it will work on more hardware because we dont have to rely on something like grub to populate the multiboot framebuffer info

<damo22>but if hurd requires grub anyway, it shouldnt really matter

<damo22>im confused, the multiboot header is populated by gnumach, so how does it get the framebuffer from grub?

<damo22>eg in boothdr.S its supposed to be :

<damo22> .long 0

<damo22> .long 1024

<damo22> .long 768

<damo22> .long 32

<damo22>im guessing these are OS preferences

<damo22>maybe we should expose /dev/multiboot

<damo22>with the info from grub

<damo22>then any userspace driver can use the framebuffer

<damo22>otherwise how will userspace read the grub multiboot info?

<damo22>or a device("framebuffer")

<damo22>hi solid_black

<solid_black>hi damo22!

<sneek>solid_black, you have 1 message!

<sneek>solid_black, jab says: You are working on a C++ bindings to gtk right? Have you ever tried using racket to make GTK apps? In my opinion, racket is the best way to build GTK apps. I would know. I've never built one!

<damo22>ive almost written a device(framebuffer_info)

<damo22>but somehow it returns an empty struct

<gnu_srs1>Hello, I'm still unhappy with Debian's merged /usr. Therefore I'm no longer contributing to Debian/GNU Hurd :(

<solid_black>:(

<solid_black>what were your thought on the Alpine-based distro?

<gnu_srs1>Still trying to keep /usr as a directory.

<solid_black>would you perhaps want to hack on that?

<gnu_srs1>solid_black: Tks. I'll take a closer look.

<solid_black>it hasn't seen much work since last winter, so the first thing we'd have to do is bring it up to date with both Alpine and Hurd

<solid_black>after that, we'd need to get netdde working

<damo22>Framebuffer address: 0xb8000

<damo22>Framebuffer pitch : 160

<damo22>Framebuffer width : 80

<damo22>Framebuffer height : 25

<damo22>Framebuffer bpp : 16

<damo22>that is passed from grub

<damo22>but when i try to expose it as a mach device with device_map it returns zero

<damo22> return (i386_btop(pmap_extract(pmap_kernel(), (vm_offset_t) fb_info_ptr)));

<damo22>i get a pointer back but the contents of mapped page is zero

<solid_black>could you upload the complete patch? I need to page in (heh) the details of the VM subsystem, and it'd be easier if I looked at the whole thing

<damo22>solid_black: https://git.zammit.org/gnumach-sv.git/log/?h=framebuffer

<solid_black>thx, /me looks

<damo22>did i implement device_map properly?

<solid_black>I don't think it can work like that

<solid_black>it needs a page-aligned address

<solid_black>and you're passing fb_info_ptr, aka &fb_info, which is just a static variable somewhere in the kernel image

<solid_black>hence, pmap_extract returns NULL

<solid_black>one thing you could do is force fb_info to page page-aligned, that should help

<solid_black>but also, is this what you want?

<solid_black>what do you expect userland to see when it looks at the mapped page?

<solid_black>the contents of 'struct multiboot_framebuffer_info'? or the framebuffer itself? i'd expect the latter

<solid_black>ah, this is an *fbinfo* device, not fb itself

<damo22>the contents of the info

<solid_black>can you make it readable instead of mmapable?

<damo22>yes, the fb is a trivial mapping once you know its address but you need to know the width/height and bpp

<solid_black>hardly seems worth an mmap for a simple struct

<damo22>i could i guess

<damo22>so i implement device_read?

<solid_black>dev_ops->d_read rather

<solid_black>did I mention how much I dislike this device framework that Mach has :|

<solid_black>how do you envision this framebuffer device actually being used? should X.Org use it? (or does it discover framebuffers on its own?) does a boot splash screen use it?

<solid_black>should there be a /dev/fb node with a translator on it?

<damo22>once userland knows the grub multiboot framebuffer, it can implement a graphical console on the existing mode

<damo22>instead of hardcoded to 0xb8000

<solid_black>ah, so it's for the console

<solid_black>so the Hurd console could be taught to pick up the existinging framebuffer instead of overwriting it?

<damo22>initially yes, but if it works on the console, theres no reason X cant use it

<damo22>or X can use the VBE console

<solid_black>does grub always discover the "best" available fb / modes?

<damo22>mostly

<damo22>the reason X is borked on corebooted machines on hurd is because it runs in EGA text mode to get a console and then X cant use the mode 3

<damo22>so step 1 is to make graphical console work on hurd

<damo22>if that works, then X will just work on the existing set up framebuffer

<damo22>using VBE

<damo22>grub already sets up a graphical console and passes the multiboot info to hurd, (pending a patch i have)

<damo22>i just need to pass the struct over to userland

<damo22>it works!!! __aligned(PAGE_SIZE)

<solid_black>just be aware that this way, you'll be also exposing whatever the kernel memory happens to contain after the fb_info

<solid_black>and you should really be checking 'off'

<damo22>well, the time device does the same thing

<damo22>you could probably overread the memory using time device

<damo22>lol

<solid_black>no, the time device specifically allocates a page to hold the time data

<solid_black>see mapable_time_init

<solid_black>that's not memory in the kernel image, that's a dynamic page it's exposing

<solid_black>but it's true that they're not checking offset (nor using it in any way), which means

<solid_black>that if you mmap the time device over a large area, you should see multiple copies of the same page

<solid_black>which should probably be fixed

<damo22>maybe i should make it a device(fb) that mmaps the actual framebuffer, and use device_get_status to inform of the sizes

<solid_black>yes, that sounds better

<solid_black>device_get_status is basically Mach for ioctl, right?

<damo22>probably

<damo22>thing is, theres no reason the fb device needs to be hosted by gnumach

<damo22>i really want to pass the info to userspace, then any translator will do

<solid_black>if it's Mach that knows its parameters, and there's not much to the driver besides exposing the parameters & the memory, I don't see why it wouldn't belong in Mach

<solid_black>it'd be a whole different thing if we were talking about some complex GPU that needs to be driver, then that'd definetely belong in userland

<damo22>it would make it easier to write, if its in gnumach, because the immc could use it too

<damo22>etc

<damo22>but then we need a font compiled into gnumach

<damo22>im gonna stick with device_read

<damo22>read out the struct as bytes to userspace

<youpi>could it make sense that gnumach just exposes the multiboot information?

<youpi>and let userland cope with it

<damo22>yes

<youpi>it definitely is gnumach that has the information, nothing else can have it

<damo22>device(mb_info)

<damo22>that would help with disk layout too

<solid_black>oh yeah, just exposing all the mb info as is makes sense to me too, and is more microkernel-y

<solid_black>(but keep in mind not every arch has mb, notably not aarch64)

<damo22>aarch64 doesnt have grub?

<solid_black>it does have grub, but not a multiboot standard

<solid_black>multiboot is only defined for 32-bit x86 and... alpha, iirc?

<damo22>multiboot is fairly agnostic isnt it?

<solid_black>people use either EFI (ugh), or "the AArch64 Linux boot protocol" on aarch64

<solid_black>gnumach boots using the latter

<solid_black>it was MIPS, not Alpha

<solid_black>the framebuffer info would be read from the device tree on aarch64

<solid_black>but since there's apparently no (common?) framebuffers supporting text mode in the arm world, we would strongly prefer for this to leave in userland

<damo22>i was able to make grub switch the video mode to a linear fb by specifying a preferred multiboot video mode

<damo22>before it handed off to mach

<damo22>ie, mach can specify if it prefers to be launched with text mode or gfx mode

<damo22>this is in the multiboot spec

<gnucode>heyo, so I gather that we are having a difficult time porting Debian's newer dhcp client: dhcpcd. What if we used OpenBSD's dhcpd? Honestly it seems like the way OpenBSD connects its computers to the internet is pretty cool. https://man.openbsd.org/dhcpd.8

<azert>solid_black: in arm64 we should absolutely expose the whole device tree as a blob and let userspace take care of configuring the drivers, I totally agree with you! In x86 the equivalent is exposing the multiboot info

<sneek>azert, you have 1 message!

<sneek>azert, gnucode says: So what you are saying is that the Hurd's console will only display on VGA? I suppose that is a given since we probably don't have drivers for HDMI or display port

<solid_black>hi azert!

<solid_black>yes, we should expose the dtb as just a blob

<solid_black>(and have a translator that exposes it as an fs tree, much like Linux)

<azert>That would be nice and in the translator spirit. One of these days I’ll get back to my board, will try to fix the memory allocation bug

<solid_black>remind me what that was?

<azert>There were two issues. The most important was that we were dynamically allocating memory that would ignore writing and read as 0xFF

<azert>this is typical behavior for memory that don’t exist

<azert>The other issue was configuring the timer, but I think that was minimal in comparison

<solid_black>ah yes, we were not getting timer interrupts

<solid_black>did we set up the interrupt controller that you have?

<azert>Partially it was because the timer setup was using dynamical memory

<azert>The interrupt controller was standard but I didn’t test it enough

<solid_black>we also really need to do something about hooking up uart to mach console

<azert>Yes there is plenty of things to do

<azert>But the memory issue was the real bummer for me

<azert>I think hacking up some drivers for the other pieces is easier then fixing that bug

<gnucode>hmmm. I'm trying to attach gdb to a hurd translator.

<gnucode>the wiki seems to think that I need hurd-dbg installed, but apt is giving me an error when I 'apt install hurd-dbg'

<gnucode>nevermind hurd-dbgsym

<gnucode>that's what it is.

<gnucode>but I've got nothing in /usr/lib/debug

<gnucode>and my gdb doesn't seem to have the hello.c debug symbols loaded.

<gnucode>hmmm. I'll figure this out eventually.

IRC channel logs

2024-10-23.log