IRC channel logs

<damo22>youpi: should i try putting a sleep after the sem_post and see if it crashes?

<damo22>then we will know if there still exists a race?

<damo22>it does not crash if you wait 5 seconds after the sem_post

<damo22>before launching the mach_msg_server

<damo22>i dont know what the sem waiting prevents then

<damo22>but it is needed for something

<damo22>path.cpp:54:14: error: ‘PATH_MAX’ was not declared in this scope

<damo22>where does that macro come from

<damo22>ahh hurd has no PATH_MAX anymore

<damo22>youpi: i am modifying libpciaccess to only request the io ports it needs

<damo22>i am working off the assumption that mach will eventually block requests to i386_perm_create for overlapping ranges and maintain a list there

<damo22>but how do i handle a process getting destroyed?

<damo22>is there any way for mach to know that a process died and thus needs to release the ports?

<damo22>otherwise i would have to maintain the list on the client

<damo22>as well

<damo22>jlledom: is there any way for mach to know that a process died and thus needs to release a set of io ports?

<jlledom>I don't know! :)

<damo22>i was just saying, i am modifying libpciaccess to only request io ports it needs

<damo22>(18:14:43) damo22: i am working off the assumption that mach will eventually block requests to i386_perm_create for overlapping ranges and maintain a list there

<damo22>but it would be so much easier if mach could know if a process that requested a bunch of ranges needs to free them all so i dont have to maintain a list on the client as well

<damo22>io ports can only be used by one process at a time, regardless of the user who opened them

<jlledom>damo22: I understand, but libpciaccess uses ioperm(), it doesn't call ithe 386_perm_create RPC

<damo22>whats the difference?

<jlledom>> io ports can only be used by one process at a time

<jlledom>I didn't know this

<youpi>damo22: it knows that through the no-sender notification. Taht's already handled

<youpi>io perm is implemented through the RPC

<jlledom>I meant, if you're worried b/c Mach wiill block requests to i386_perm_create, will it affect livbpciaccess which is calling ioperm()?

<jlledom>ok

<youpi>actually, I don't think you can make libpciaccess request only the required ports

<youpi>because the application doesn't actually tell what pci devices it will be using

<damo22>really??

<youpi>or is that pci_device_enable ?

<youpi>I don't know

<youpi>but I wouldn't be suprised that it doesn't

<damo22>pci_device_open_legacy_io

<damo22>struct pci_io_handle *

<damo22>pci_legacy_open_io(struct pci_device *dev, pciaddr_t base, pciaddr_t size)

<damo22>i think that is what X11 must be using?

<youpi>ok, so we need to be sure that applications actually do call that once per pci card it wants to drive

<youpi>that's not for sure

<damo22>struct pci_io_handle *

<damo22>pci_device_open_io(struct pci_device *dev, pciaddr_t base, pciaddr_t size)

<damo22>this one is better

<youpi>ah, linux uses /sys/.../legacy_io

<youpi>so we should be good then

<youpi>since linux makes it mandatory to use proper access

<damo22>ok

<damo22>if a process that calls ioperm(0, 7, 1); dies after making that call, does something trigger in the kernel for no-sender

<youpi> /* Our ``no senders'' handling routine. Deallocate the object. */

<youpi>static

<youpi>void

<youpi>no_senders (mach_no_senders_notification_t *notification)

<damo22>what would happen?

<damo22>so i could store a list of ranges in emul_data?

<damo22>or io_perm_t

<damo22>struct io_perm has from and to

<damo22>is there a way to address all io_perms?

<youpi>you'll get a no sender for each port

<youpi>(mach port)

<damo22>yes but i need to check all of them when deciding if its okay to grant the next

<youpi>you can simply use a global bitmap

<jlledom>coldn't libpciaccess call ioperm() when it probes a device and finds an IO region, only for those region IO ports, instead of calling ioperm(0, 0xffff, 1) once at startup?

<damo22>jlledom: i am working on that yes

<damo22>but the kernel needs to deny access to any range that already overlaps the request

<youpi>yes, and a global bitmap will work

<damo22>global bitmap? theres 65536 possible ports

<youpi>that's 8KB

<damo22>put a bool in each one?

<damo22>or one bit

<youpi>well, a bitmap

<youpi>an array of bits

<youpi>you already have the functions in io_per!.c

<youpi>s/perl/pem

<youpi>just not the overlap-testing one, but that's easy to write