IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>youpi: do you have an idea how to fix interrupt handling properly so it can be merged into gnumach?
<damo22>ie, the TODO and FIXME in the debian patches
<damo22>i want to be in a position where we can add rumpdisk and not juggling pending interrupt patches
<damo22>last time we spoke, the idea was to introduce irq and ioperm as devices
<damo22>youpi: could ioperm access be managed by the auth server? why do we need separate permissions for i/o ports? as i understand it, calling ioperm() grants the user access to certain i/o ports, but why can't these permissions just be inherited
<damo22>via some kind of capability
<damo22>or maybe the pci-arbiter should manage ioports so it can be done per device
<damo22>hmm but some ioports are not associated to a pci device?
<youpi>damo22: making ioperm a device inside gnumach would precisely allow to manage this through unix perms
<youpi>root can use the device anyway, but a devnode can be added in /dev with some perms for non-root to access it
<youpi>though normally only root process would need to access it
<youpi>concerning XXX / FIXME, what needs to be fixed is written there
<damo22>which commit of gnumach should i be basing this work on?
<youpi>? well master ?
<youpi>ah you mean where to put your work?
<youpi>there's a device branch there
<damo22>no i can keep it locally
<damo22>i mean, i need irqs
<damo22>i rather not apply random patches, just official ones
<youpi>that branch is what is official-just-not-commited-because-awful
<youpi>and with the -debian branch on top, is what is in the debian package
<youpi>see what's the debian patches say
<youpi>they explicitly ther's coming from there
<damo22>i will start from this commit * 640b447b (origin/master-user_level_drivers) Fix file name order
<damo22>to see if i can produce an alternative "-debian" patchset that will be something that can be committed
<youpi>that's the last commit on theb ranch yes
<damo22>i think i need to fork off that commit so i can introduce an alternative that doesnt break anything, then i can rebase it onto master later if we want to commit it to master
<youpi>we'll squash everything before commiting to master
<youpi>but yes you can work on a second branch, to keep the first as "ugly but stable"
<damo22>is the port supposed to be "100" instead of "424242" in the final version?
<youpi>(msg id more precisely)
<damo22>ok i'll try to keep that in mind
<youpi>that's the point of the -debian branch, just rename / renumber
<damo22>it appears this has been waiting to be done like this for a while
<youpi>yes, like so many things that people don't like to spend time on, and rather experiment on yet other stuff that won't be finished either
<damo22>i might need some help to design the pci protocol later on
<damo22>but this irq/ioperm stuff is a nice little project
<damo22>the "experimental" server might actually disappear because it wont need to be demuxed, instead an irq device will be exposed
<damo22>so under the new irq device scheme, how would a gnumach "device" such as an in-kernel disk driver access an irq?
<damo22>can a device open another device?
<youpi>it doesn't need to, it can use the internal gnumach interface
<damo22>youpi: do you think it could make sense to have an array of irq devices, one per line?
<youpi>damo22: that could work, yes
<damo22>i think it works better in terms of granular access control, as well as simplifying the device structs
<youpi>(thinking about it, it may be a smaller exercice to move the i386 ports to a device_open() first)
<damo22>youpi: i was thinking something like this
<youpi>as mentioned in the TODO, enable is probably not a good name since there's no actual need (or possibility) for disable, and what we need is rather acknowledgment
<youpi>I don't think there's a deliver method? it's a notification
<youpi>what is the rcv_port meant for?
<youpi>there's only the port on which doing the notification
<youpi>"line" would have to be an arch-specific thing
<damo22>yeah so how would i add an arch specific override
<youpi>I dont' rermember how gnumach usually does it exactly, but I guess through arch-specific .h files that the generic file would include
<damo22>but in a struct?
<youpi>make the arch-specific header define a struct
<damo22>im not sure how to make a struct member arch specific, unless i just add a generic member and have it set differently in different arches
<youpi>again, I don't remember how gnumach usually does it
<youpi>but that's the kind of thing
<youpi>you'd include the per-arch struct in the generic struct
<youpi>and let the per-arch code access it, possibly defined by macros
<damo22>i see
<youpi>again, really, read the source code to see how it's done in other parts
<youpi>that's how everybody learns
<youpi>that's how I learnt everything I know
<youpi>(no I didn't get born with everything I know today)
<damo22>why not put "int irq_number;" which is just a simple enumeration of the irq devices and add a method get_arch_line() that can map between them for different arches
<damo22>and in the simplest case it is a 1:1 mapping
<youpi>who knows what an irq can be
<youpi>there can be several numbering
<youpi>it may even not make sense to number
<youpi>that's one way for sure, just comments
<damo22>i thought an irq is always a number
<youpi>on x86 yes
<youpi>though with apic etc. that's less and less clear
<youpi>see your /proc/interrupts
<damo22>mine are all numbered except NMI which is a number anyway on x86
<damo22>so it needs to be an arch specific struct {} to map it onto something the machine knows
<damo22>hmm so irq cannot live in device/
<damo22>because it is machine dependent
<youpi>is the ack management not generic?
<damo22>sorry my brain isnt working now its too late
<jrtc27>pft who needs more than two cascaded 8259s