IRC channel 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>okay

<damo22>which commit of gnumach should i be basing this work on?

<youpi>? well master ?

<damo22>sv?

<youpi>ah you mean where to put your work?

<youpi>there's a device branch there

<damo22>no i can keep it locally

<youpi>master-user_level_drivers

<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

<damo22>ok

<youpi>and with the -debian branch on top, is what is in the debian package

<damo22>great

<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

<damo22>yeah

<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>yes

<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

<youpi>yes

<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>ok

<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 https://paste.debian.net/plain/1154093

<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

<damo22>ok

<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>okay

<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

<damo22>ok

<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>:D

<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

<youpi> http://paste.debian.net/1154097/

<damo22>ok