IRC channel logs
2024-03-12.log
back to list of logs
<gnucode>sneek later tell LSxAutumn that I use a T43. Also you can ask on bug-hurd@gnu.org I believe the T43 also works on real hardware. And some others. <damo22>where is man pthread_mutex_init ? <damo22>$ gcc -D__KERNEL__ -I../../include/ -c intel8x0.c -o intel8x0.o <damo22>i wrote enough glue code to compile part of a pci audio driver unmodified from the linux source tree :D <solid_black>damo22: do you have an understanding of how to make something into a Mach device sanely, so it can be device_open'ed etc? <solid_black>there is the static table at conf.c, but that is just sad <solid_black>I want to add devices dynamically as they are discovered (from the device tree), and make it keep a pointer to my device structure instead of relying on minor numbers <solid_black>the existing Mach device framework seems focused on providing enough duck-tape to run old Unix drivers <damo22>cant you use a static table like conf.c but it detects the hw <solid_black>which -- I don't even think there are, except for com/immc <damo22>or do you mean you have a list of devices that are dynamically added <solid_black>even if I had a dynamic list, it doesn' buy me much, since it's still base on minor numbers, not pointers <damo22>i dont know what a minor number is <solid_black>that's how devices used to be identified in old Unix, by a pair of (major, minor) numbers <solid_black>a device node on the filesystem, /dev/foo, contains the two numbers in its metadata <solid_black>and when you open("/dev/foo"), Unix kernel uses the two numbers to find the driver handling the device and pass the request to it <solid_black>major number is the index of the driver, among all drivers, e.g. all hd* devices are handled by a single drivers and so share the major number <solid_black>and minor number is the index of the device within the drivers <solid_black>e.g. /dev/hda could be (5, 0), /dev/hdb (5, 1), /dev/hdc (5, 2), /dev/sda (6, 0), /dev/sdb (6, 1) <solid_black>mknod(1) is how you make these device nodes on Unix, you just do "mknod /dev/foo 6 0", and voila, you can now open /dev/foo and it will behave just like /dev/sda (assuming 6 is sd's major number) <damo22>are there major numbers reserved per device? <solid_black>today things are more dynamic, and yet today's Unices keep the same API <solid_black>so e.g. on Linux, your device drivers doesn't have a fixed pre-reserve major number, it requests to get allocated a major number dynamically <solid_black>and then the assigned major number and the driver's name are exported to userland somehow (through sysfs? not sure), and udev picks them up and creates the device nodes with the name and assigned major number automatically <solid_black>on the Hurd, the dynamic /dev/ node creation thing doesn't happen (we don't have a /hurd/devfs, though that'd be nice), so we use the MAKEDEV script <solid_black>but, the Hurd doesn't use major/minor numbers either, we use translator records <solid_black>'s a "/hurd/storeio -T device hd0" (or whatever) translator record <solid_black>so devices are really identified by names, not numbers, in Mach <solid_black>but, inside Mach, the device handling code still maps the name to essentially a (struct dev_ops, minor number) pair <solid_black>which makes sense if what you have is a bunch of Unix drivers that you want to run in your shiny new microkernel thing without rewriting them <solid_black>and makes less sense if what you have is an old microkernel from the 80s and are trying to port it to a new architecture that didn't exist until 2010s, and writing new drivers for it <azert>The way Mach devices detect hardware, <azert> make themselves known to servers, etc. <azert> is currently a horrendous kludge and needs replacing. <azert> Anyone interested in doing this, please contact me <azert> and I'll give you more details about what I have in mind. <azert>I think this is what gnumach is based on <solid_black>yes, this is the same code as in gnumach, except it looks like gnumach's been through some cosmetic refactorings (K&R C -> ANSI) <youpi>solid_black: I don't see why the static dev_name_list table would be a problem in your case? the major number will just represent your driver, which should be fine, and then it just uses a minor number (the "unit" number), which you can make represent whatever way you prefer, by numbering devices as you discover them in the device tree <youpi>I mean, of course having a devfs would be better, to populate /dev as the hardware fits, but I don't think this is a blocker for devicetree-based hardware? <solid_black>this is not about userland or /dev yet, I just brought that up for explaining what device numbers are <solid_black>that's the thing, I don't want to have major/minor numbers <solid_black>there can be different UARTmodels, implemented by different drivers <youpi>depends who you ask :) but yeah <youpi>bsd systems used to have very different names for disks & network devices :) <youpi>but ok, now I understand what you mean <solid_black>there can be multiple different models attached at the same time, or there can be multiple instances of a single model <solid_black>I want it to end up calling e.g. pl011_write(struct pl011 *) when the user calls device_write() <youpi>there's not much other possibility than having a dynamic registration s ystem <youpi>that you plug between dev_name_list and comopen <youpi>and whichever is probed first gets unit 0 number <solid_black>yes, so that could be done by adding the third layer of indirection <damo22>i dont want to have ALSA-like issues with com ports, eg, the device id changes between boots <solid_black>as long as the device tree stays stable (and we don't learn to somehow discover uarts in a different way), they won't <youpi>with device trees you'd have stable ordering <solid_black>youpi: more meta question, how/when would you like all the aarch64 things to get merged/upstreamed? <youpi>the real rule of thumb is to avoid abi breaks <solid_black>apparently nobody wants to review my glibc patchset, but they're ok with merging it if aarch64 support was in gnumach upstream <youpi>also, committing code that is known not to work is not a good idea either <solid_black>the cool thing is the ABI turned out to be totally compatible between my glibc port and gnumach port! <youpi>yes, that's how ports work: everybody is already heavy-loaded, so they can't really magically find time to review a new port <youpi>and they expect us to maintain it <solid_black>as in, I have not rebuilt the simple glibc test executable since I ported glibc in December <youpi>as long as the rest is not broken, that works <youpi>basically, I'd say we can commit code that we believe won't change to get userland programs working at least basically <damo22>i am kind of eager to get support for another arch, but at the same time, reluctant to have to touch other ports if working on i386 in gnumach <solid_black>youpi: I don't think I understood that last message, could you rephrase? <youpi>I mean that if you have something that gets to run userland at least basically and won't rework it all for the rest of porting, we can commit it <youpi>the problem in source code repositories is big refactories <youpi>so if we can avoid that because the first version was actually too experimental, better do so <solid_black>I do have something that runs userland code, both Luca's tests, which all pass, and the simple glibc program <youpi>but if further commits are just about adding drivers or extending the infrastructure already in place, that's not a problem <youpi>and no big refactor is expected to run the rest of an actual userland system? <solid_black>but at the same time, hardware/peripheral support is not quite there yet, it doesn't fully boot on anything but qemu's virt machine, and you cannot even device_open("console") (nor "com0"), since the UART is not exposed as a Mach device yet <solid_black>we may need some imporovements (but mot huge refactors) in the pmap subsystem to run a fuller userland, it kind of grew organically <youpi>that's fine, drivers are quite separate from what you already have (boot, mm, system calls) <solid_black>and PAC is not yet supported, nor is BTI for userland (BTI for the kernel itself is, and works) <solid_black>also the multiboot-less bootstrap integration is kind of hacky, and probably broke i386 <damo22>im concerned there might need to be some refactoring in gnumach to better support other arches <solid_black>most of gnumach is already portable / ready for ports <solid_black>but it's less prepared to deal with modern hardware setups / boards / peripherals <solid_black>the second place (besides gsync) that didn't properly use copyin()/copyout() to access user memory was mach_print() <solid_black>also no big deal security-wise, but it instantly led to a panic once I got PAN working ;) <solid_black>also made mach_print return kern_return_t rather than void, not that anybody is going to check the return value <azert>solid_black: in regard to hardening, just out of curiosity, did you already implement devices DMA? Is there any reason to believe that you will need refactoring to support SMMUs? <azert>Or the CCIs (cache coherent interfaces) <azert>Apparently the Raspberry pi don’t have those <solid_black>I have not done anything w/ DMA, and I have no idea what SMMU or CCI are :) <solid_black>I'm still not a device person, even though I'm making my first steps in this area <solid_black>and it sounds like you know what those are, meaning that you know more than me, so you're very welcome to contribute! <solid_black>"The SMMU protects the system from DMA controlled by a malicious or incorrect userspace program." I don't think we have unprivileged device drivers? <solid_black>though that'd be interesting, basically they'd start up as root (to get device master etc) and then drop privs <azert>solid_black: exactly! It’s a mechanism to ensure that a malicious actor exploiting a driver cannot take over the system <azert>In regards to performances I’ve also many doubts. Maybe true that you can get better performances in user space if there is a single user of a driver <Pellescours>youpi: doing a `ls /dev` does not show /dev/cons as a directory but if you do a `ls /dev/cons/` you see sub-entries. I know it’s a file backed by translator but isn’t it a regression that it does not display as a directory? Maybe it never was for /dev/cons but I think some transated files into directory (httpfs?) are shown as directory <azert>Also I suspect that with an SMMUs and CCI it is possible to map a buffer on a piece of hardware directly in the memory of a task. That might give you good performances for different things <azert>Think e.g. a frame buffer or a command buffer for gpgpu <youpi>Pellescours: that probably needs fixing, yes <solid_black>I had a patch somewhere to disable it with a long explanation why in the commit message <Pellescours>youpi: do you have a hint where the bug could be? I don’t know enough the hurd api yet <youpi>yes, sure, it's most probably the stat rpc <youpi>but how exactly, which stat implementation etc., I don't know without looking at the code <youpi>you can use ldd /hurd/console to check what library it's using and thus which implementation <youpi>and thus get the stat implementation <youpi>but not sure if it's indeed there <youpi>but at least you can put prints etc. to check what's happening <youpi>but how is it that /proc doesn't have the issue? <youpi>is that just because the underlying node is a directory? <youpi>if so then doesn't flavio's MAKEDEV patch fix it? <solid_black>do you know if there's something like '-z rewrite-endbr' in GNU ld? (and preferably with aarch64 support...) <Pellescours>youpi: I don’t think the flavio’s MAKEDEV patch can fix this issue. The node /dev/cons is defined by the console itself (hurd: console-client/console.c:45 & hurd: console-client/trans.c:879) <youpi>yes but the underlying node is set by MAKEDEV <Pellescours>I don’t see `/dev/cons` appearing in MAKEDEV, is it really set by it? <youpi>then it's console_setup_node that could rather make it a directory indeed <youpi>yes but that's not the underlying node <Pellescours>so I need to add S_IFDIR to the file_name_lookup() call ? <Pellescours>Isn’t the netfs role to make the node appear as a dir if the underlying node is a file?