IRC channel logs

<lakeblue>re: hurd headers: i found how to do it, https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html, at Installing Headers

<damo22>youpi: what could be causing this trivfs to return 255 on ioctl? https://git.zammit.org/hurd-sv.git/commit/?h=drm-server

<damo22>it almost works

<damo22>solid_black: ping

<damo22>why would mig be generating this massive message size? _Static_assert(sizeof(drm_version_t) == 4 * 1545, "expected drm_version_t to be size 4 * 1545");

<damo22>msgt_number = 1545

<lakeblue>just got the cross compilation environment for hurd working. yay!

<lakeblue>i'm amazed the web server worked first try on hurd

<damo22>im having trouble setting a mig struct type as an "out" parameter, it seems to not understand its length

<damo22>how do i fix this?

<damo22>eg:

<damo22>routine drmioctl_version (

<damo22> port: drm_t;

<damo22> out version: drm_version_t);

<solid_black>damo22: pong, hi

<solid_black>data_t name; << data_t is a MIG array, isn't it

<solid_black>I don't think you can use it as a struct field like that

<solid_black>and I'd expect MIG to complain loudly when you do try to use it, instead of just generating broken code

<solid_black>you could ask Flavio to make it error out earlier about this

<solid_black>where do you even expect this 'name' pointer to point? OOL data in the message? what about the ioctl?

<solid_black>or is it supposed to be an inline variable-size array, prefixed by its length?

<solid_black>in any case, the glibc-side ioctl implementation cannot grok anything complex like that

<solid_black>my intuition would be to implement drm APIs as a poper RPC subsystem rather than mimicing Linux ioctls, and have a separate Hurd backend in libdrm

<damo22>cant you put a pointer into an ioctl?

<solid_black>I don't think so, where do you expect it will point?

<damo22>how does linux drm work then?

<damo22>they use char *name

<damo22>within the ioctl

<solid_black>might be a good idea to check how it works on Linux first indeed :)

<solid_black>see, in Mach IPC, it's OK for data to just appear in recepient's address space, as new pages where nothing else was mapped

<solid_black>Unix doesn't do that

<damo22>i think it expects the caller to write to the address pointing to kernel memory?

<damo22>idk

<damo22>no

<damo22>the caller sends a pointer to its local address space and the ioctl writes to the buffer?

<solid_black>that could work (on Linux), but is it how it actually works?

<damo22>i think so

<damo22>err = drm_copy_field(version->name, &version->name_len,

<damo22> dev->driver->name);

<damo22>copy_to_user

<solid_black>in any case, the Hurd ioctl implementation in glibc can only deal with simple structures of (char, int16, int32, int64)

<solid_black>see sysdeps/mach/hurd/ioctl.c

<solid_black>nothing more complex like pointers

<damo22>ugh

<damo22>how do i implement a compatible interface then?

<solid_black>give up on making it based on ioctls

<solid_black>make it a proper MIG susbsystem

<solid_black>write a backend for libdrm that calls those routines

<solid_black>instead of ioctls

<damo22>ok

<damo22>its mostly compatible, just not the pointers

<solid_black>ioctl is really not a good API for anything, Linux just uses it 'cause they don't have a better API to do RPC / extensible syscalls; we do, it's called Mach IPC :)

<damo22>:D

<damo22>can i reuse my code? i have implemented most of the ioctl way

<damo22>ive implemented all the stubs

<solid_black>yeah I imagine most of the implementation doesn't care whether the RPC is supposed to be usable as an ioctl

<damo22>but i still have a problem, dont i need to implement mig types?

<damo22>so mig can generate the interface

<damo22>so i need to stick to simpler structures

<damo22>then, it doesnt even matter if its an ioctl or not

<solid_black>in no-ioctl MIG, you could just do routine drm_get_version(port: drm_t; out version_major: int; out version_min: int; ... out name: string_t; ...);

<damo22>oh i dont need to stuff everything into a simpler struct

<solid_black>or maybe you _can_ put data_t into a new-style struct?

<damo22>new-style?

<solid_black>there are classic structs, which are only structs in the name but really arrays of integers

<solid_black>and Flavio's new C-like structs

<solid_black>you're using the latter ones

<solid_black>but I'm not very familiar with their semantics

<damo22>struct[4] of int

<damo22>is old?

<solid_black>is

<solid_black>yes

<damo22>type io_statbuf_spare_int = struct[8] of int;

<damo22>type io_statbuf_t = struct {

<damo22>...

<damo22>io_statbuf_spare_int st_spare;

<damo22>}

<damo22>that seems to work

<damo22>so you can nest the types, but you probably cant put pointers in there

<solid_black>yes, but also maybe you can, not sure

<solid_black>you should ask Flavio

<damo22>flavioc: ^ ?

<solid_black>but if you got a static assertion failure once you've tried, it's a good indication that it doesn't work

<damo22>but what good would a pointer be from the other side of the rpc?

<solid_black>MIG does the right thing with them

<solid_black>i.e. it's not just a pointer, it's a buffer which gets copied, and the receiver gets a pointer in its own adress space pointing to the received data

<solid_black>you wouldn't need spearate _len parameters at the MIG level

<damo22>how do you specify a pointer type

<damo22>in mig

<damo22>type arr_t = array[] of int; ?

<solid_black>I gotta run, but look at how strings are passed around elsehwere, in other subsystems

<damo22>ok

<damo22>argv: data_t SCP

<azert>damo22: I think it is a bad idea to drift away from the Linux implementation api wise

<azert>Just keep it the same and improve mig/glibc instead

<azert>If something is not usable as an ioctl, use it as an rpc for the moment

<azert>But adding parameters is a bad idea

<damo22>that contradicts the other advice i got, and ive already been refactoring it

<azert>damo22: it’s not clear why you want to change the api

<azert>If it’s just that glibc cannot handle such complex ioctl then use them as rpc: they are rpcs

<damo22>i am but i cant pass pointers

<azert>userspace pointers?

<damo22>the kernel isnt sharing the address space?

<azert>That’s what iowrite does

<damo22>mig understands how to copy 2048 byte strings

<damo22>but nothing else i think

<azert>routine io_write (

<azert> io_object: io_t;

<azert> RPT

<azert> data: data_t SCP;

<azert> offset: loff_t;

<azert> out amount: vm_size_t);

<azert>What about data ?

<azert>routine io_read (

<azert> io_object: io_t;

<azert> RPT

<azert> out data: data_t, dealloc;

<azert> offset: loff_t;

<azert> amount: vm_size_t);

<azert>Oh

<damo22>the drm api is strange

<damo22>it passes around virtual kernel addresses

<damo22>i dont know how that works

<damo22>unless it defers the writes to the kernel itself and just stores the pointers for later

<azert>You can do the same in the hurd

<damo22>wrangling with mig is a pita

<azert>Give an example of these kernel address uses

<damo22>struct drm_buf_map {

<damo22> int count; /**< Length of the buffer list */

<damo22> void __user *virtual; /**< Mmap'd area in user-virtual */

<damo22> struct drm_buf_pub __user *list; /**< Buffer information */

<damo22>};

<azert>btw a pointer is just an integer

<azert>You mean the virtual field?

<damo22>yes i mean i can pass pointers anywhere

<damo22>but dereferencing them from kernel -> user is not allowed

<azert>I think gnumach allows mapping the page in the server address space

<azert>That is what io_read and io_write rpc do

<damo22>nested structs are a pain to deal with in mig

<azert>On the other hand, you probably want an Hurd api to be totally different using memory objects and such

<azert>damo22: I understand

<damo22>so i have been flattening some of them

<damo22>but sometimes there are arrays of structs

<damo22>i dont know what to do with them

<azert>I don’t think flattening is the solution

<azert>Either one works on mig to make him understand these things, which may be impossible, or one redesign the api in the hurdish sense

<azert>Which means memory objects

<azert>And pagers

<azert>I think drm is implementing something like this: https://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html#External-Memory-Management

<azert>But I’m not sure everything is in place even..

<damo22>the point of drm is to abstract the hardware specific detail of 3d acceleration to a common api

<damo22>the cards need to allocate memory on themselves and transfer pixel data to and from the card

<azert>That’s why I was pointing out the pager gnumach api

<damo22>but for our dummy driver, it should be a trivial implementation

<damo22>the problem is there are ~200 stubs

<azert>I think that if you formulate the issues clearly, solid_black and youpi have the solutions

<damo22>my branch builds now

<damo22>i need to choose a better subsystem id

<damo22>as its not ioctl

<damo22>$ sudo settrans -fga c ./drm

<damo22>crw-rw-r-- 1 demo demo 0, 0 Nov 2 21:22 c

<damo22>-rwxrwxr-x 1 demo demo 170828 Nov 2 21:20 drm

<almuhs>the party has finished? I forgot Spain changing timezone

IRC channel logs

2024-11-02.log