Re: gnumach: [PATCH] - irq as a mach device
Hi,
On 3/7/20 7:29 pm, Damien Zammit wrote:
> I have tried to refactor the RPCs but I'm not sure how to make it a
> fully-fledged "irq" mach device.
I have a new version of my patch that should make this a proper mach device and
I fixed the RPCs for ds_device_intr_*
to use device_t dev instead of mach_port_t master_port.
This patch applies cleanly to:
640b447b (origin/master-user_level_drivers)
See attached.
Thanks,
Damien
>From c4cbaa810d34bd0dc62fbe0bad8961b7220c2a36 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sat, 27 Jun 2020 22:57:51 +1000
Subject: [PATCH] irq: Refactor interrupt handling as a mach device
---
Makefrag.am | 4 +-
device/dev_hdr.h | 9 +
device/ds_routines.c | 77
device/ds_routines.h | 3 -
device/intr.h| 37
device/{intr.c => irq.c} | 289 +++
device/irq.h | 48 +
i386/Makefrag.am | 2 +
i386/i386/irq.c | 30
i386/i386/irq.h | 13 ++
i386/i386/pic.c | 54 ++
i386/i386/pic.h | 2 +
i386/i386at/conf.c | 8 +
include/device/device.defs | 20 +--
include/device/notify.defs | 2 +-
include/device/notify.h | 2 +-
kern/startup.c | 2 +-
linux/dev/arch/i386/kernel/irq.c | 53 +-
18 files changed, 365 insertions(+), 290 deletions(-)
delete mode 100644 device/intr.h
rename device/{intr.c => irq.c} (51%)
create mode 100644 device/irq.h
create mode 100644 i386/i386/irq.c
create mode 100644 i386/i386/irq.h
diff --git a/Makefrag.am b/Makefrag.am
index 73508350..d8147a40 100644
--- a/Makefrag.am
+++ b/Makefrag.am
@@ -313,8 +313,8 @@ libkernel_a_SOURCES += \
device/ds_routines.h \
device/if_ether.h \
device/if_hdr.h \
- device/intr.c \
- device/intr.h \
+ device/irq.c \
+ device/irq.h \
device/io_req.h \
device/net_io.c \
device/net_io.h \
diff --git a/device/dev_hdr.h b/device/dev_hdr.h
index ad98e0bb..4bd12c1c 100644
--- a/device/dev_hdr.h
+++ b/device/dev_hdr.h
@@ -146,4 +146,13 @@ extern void dev_set_indirection(
dev_ops_t ops,
int unit);
+/*
+ * compare device name
+ */
+extern boolean_t __attribute__ ((pure))
+name_equal(
+const char *src,
+int len,
+const char *target);
+
#endif /* _DEVICE_DEV_HDR_H_ */
diff --git a/device/ds_routines.c b/device/ds_routines.c
index 13c9a63e..2e231c54 100644
--- a/device/ds_routines.c
+++ b/device/ds_routines.c
@@ -92,9 +92,9 @@
#include
#include
#include
-#include
#include
+#include
#ifdef LINUX_DEV
extern struct device_emulation_ops linux_block_emulation_ops;
@@ -321,44 +321,40 @@ ds_device_map (device_t dev, vm_prot_t prot, vm_offset_t offset,
/* TODO: missing deregister support */
io_return_t
-ds_device_intr_register (ipc_port_t master_port, int line,
- int id, int flags, ipc_port_t receive_port)
+ds_device_intr_register (device_t dev, int id,
+ int flags, ipc_port_t receive_port)
{
-#ifdef MACH_XEN
- return D_INVALID_OPERATION;
-#else /* MACH_XEN */
- io_return_t ret;
+ kern_return_t err;
+ mach_device_t mdev = dev->emul_data;
- /* Open must be called on the master device port. */
- if (master_port != master_device_port)
-return D_INVALID_OPERATION;
+ /* Refuse if device is dead or not completely open. */
+ if (dev == DEVICE_NULL)
+return D_NO_SUCH_DEVICE;
- /* XXX: move to arch-specific */
- if (line < 0 || line >= 16)
+ /* Must be called on the irq device only */
+ if (! name_equal(mdev->dev_ops->d_name, 3, "irq"))
return D_INVALID_OPERATION;
- user_intr_t *user_intr = insert_intr_entry (line, receive_port);
- if (!user_intr)
-return D_NO_MEMORY;
// TODO The original port should be replaced
- // when the same device driver calls it again,
+ // when the same device driver calls it again,
// in order to handle the case that the device driver crashes and restarts.
- ret = install_user_intr_handler (line, flags, user_intr);
-
- if (ret == 0)
- {
-/* If the port is installed successfully, increase its reference by 1.
- * Thus, the port won't be destroyed after its task is terminated. */
-ip_reference (receive_port);
-
-/* For now netdde calls device_intr_enable once after registration. Assume
- * it does so for now. When we move to IRQ acknowledgment convention we will
- * change this. */
-__disable_irq (line);
- }
-
- return ret;
-#endif /* MACH_XEN */
+ user_intr_t *e = insert_intr_entry (&irqtab, id, receive_port);
+ if (!e)
+return D_NO_MEMORY;
+
+ err = install_user_intr_handler (&irqtab, id, flags, e);
+ if (err == D_SUCCESS)
+{
+ /* If the port is installed successfully, increase its reference by 1.
+ * Thus, the port won't be destroyed after its task is terminated. */
+ ip_reference (recei
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Tonight, I was testing the same laptop in many others GNU/Linux distributions, to check the running of Xorg in these. By example, Ubuntu 11.04. https://pastebin.com/3riq9bVG And Ubuntu 8.04 https://paste.debian.net/1155061 Checking this, It seems that my video card requires an "intel" Xorg driver, which is not available in the Hurd. But, anyways, some reports from Linux users, advice that this video card can be compatible with VESA, telling that sometimes Xorg runs using VESA instead "intel" driver, https://bugzilla.redhat.com/show_bug.cgi?id=1036016 So, maybe there could exist any possibility to run Xorg using VESA... what do you think? El vie., 3 jul. 2020 a las 21:49, Almudena Garcia (< liberamenso10...@gmail.com>) escribió: > I tested Xorg in a Debian GNU/Linux 10, over the same machine. > The log is here > > https://pastebin.com/KdacQNvE > > Maybe this can be useful to solve the problem in Hurd > > El vie., 3 jul. 2020 a las 20:15, Almudena Garcia (< > liberamenso10...@gmail.com>) escribió: > >> This is my *lspci* output >> >> http://sprunge.us/fjlTXZ >> >> El vie., 3 jul. 2020 a las 20:05, Almudena Garcia (< >> liberamenso10...@gmail.com>) escribió: >> >>> > Ok, so no hidden trick behind fbdev. It just seems your BIOS is not >>> > providing the VESA interface :/ >>> >>> Is there any way to check this? The laptop is a Thinkpad T60 type 1951 >>> >>> >>> El vie., 3 jul. 2020 a las 19:59, Samuel Thibault (< >>> samuel.thiba...@gnu.org>) escribió: >>> Almudena Garcia, le ven. 03 juil. 2020 19:04:13 +0200, a ecrit: > > Could you still post the resulting log? > > Here is the log > > [1]http://sprunge.us/3nCFzP Ok, so no hidden trick behind fbdev. It just seems your BIOS is not providing the VESA interface :/ Samuel >>>
Re: Problems in Debian GNU/Hurd with Xorg and GCC
I tested Xorg in a Debian GNU/Linux 10, over the same machine. The log is here https://pastebin.com/KdacQNvE Maybe this can be useful to solve the problem in Hurd El vie., 3 jul. 2020 a las 20:15, Almudena Garcia (< liberamenso10...@gmail.com>) escribió: > This is my *lspci* output > > http://sprunge.us/fjlTXZ > > El vie., 3 jul. 2020 a las 20:05, Almudena Garcia (< > liberamenso10...@gmail.com>) escribió: > >> > Ok, so no hidden trick behind fbdev. It just seems your BIOS is not >> > providing the VESA interface :/ >> >> Is there any way to check this? The laptop is a Thinkpad T60 type 1951 >> >> >> El vie., 3 jul. 2020 a las 19:59, Samuel Thibault (< >> samuel.thiba...@gnu.org>) escribió: >> >>> Almudena Garcia, le ven. 03 juil. 2020 19:04:13 +0200, a ecrit: >>> > > Could you still post the resulting log? >>> > >>> > Here is the log >>> > >>> > [1]http://sprunge.us/3nCFzP >>> >>> Ok, so no hidden trick behind fbdev. It just seems your BIOS is not >>> providing the VESA interface :/ >>> >>> Samuel >>> >>
Re: Problems in Debian GNU/Hurd with Xorg and GCC
This is my *lspci* output http://sprunge.us/fjlTXZ El vie., 3 jul. 2020 a las 20:05, Almudena Garcia (< liberamenso10...@gmail.com>) escribió: > > Ok, so no hidden trick behind fbdev. It just seems your BIOS is not > > providing the VESA interface :/ > > Is there any way to check this? The laptop is a Thinkpad T60 type 1951 > > > El vie., 3 jul. 2020 a las 19:59, Samuel Thibault (< > samuel.thiba...@gnu.org>) escribió: > >> Almudena Garcia, le ven. 03 juil. 2020 19:04:13 +0200, a ecrit: >> > > Could you still post the resulting log? >> > >> > Here is the log >> > >> > [1]http://sprunge.us/3nCFzP >> >> Ok, so no hidden trick behind fbdev. It just seems your BIOS is not >> providing the VESA interface :/ >> >> Samuel >> >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
> Ok, so no hidden trick behind fbdev. It just seems your BIOS is not > providing the VESA interface :/ Is there any way to check this? The laptop is a Thinkpad T60 type 1951 El vie., 3 jul. 2020 a las 19:59, Samuel Thibault () escribió: > Almudena Garcia, le ven. 03 juil. 2020 19:04:13 +0200, a ecrit: > > > Could you still post the resulting log? > > > > Here is the log > > > > [1]http://sprunge.us/3nCFzP > > Ok, so no hidden trick behind fbdev. It just seems your BIOS is not > providing the VESA interface :/ > > Samuel >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 19:04:13 +0200, a ecrit: > > Could you still post the resulting log? > > Here is the log > > [1]http://sprunge.us/3nCFzP Ok, so no hidden trick behind fbdev. It just seems your BIOS is not providing the VESA interface :/ Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
> Could you still post the resulting log? Here is the log http://sprunge.us/3nCFzP El vie., 3 jul. 2020 a las 18:44, Samuel Thibault () escribió: > Almudena Garcia, le ven. 03 juil. 2020 18:29:31 +0200, a ecrit: > > > Possibly fbdev gets in the way, and it wouldn't work anyway, so > > > try to remove the xserver-xorg-video-fbdev package for a start. > > > > I removed It, but this doesn't solve the problem > > Could you still post the resulting log? > > Samuel > >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 18:29:31 +0200, a ecrit: > > Possibly fbdev gets in the way, and it wouldn't work anyway, so > > try to remove the xserver-xorg-video-fbdev package for a start. > > I removed It, but this doesn't solve the problem Could you still post the resulting log? Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
> Also, it's not the 90s any more :). Yep, we need more repositories' maintainers for Debian GNU/Hurd El vie., 3 jul. 2020 a las 18:37, Richard Braun () escribió: > On Fri, Jul 03, 2020 at 06:13:16PM +0200, Samuel Thibault wrote: > > It's not "every" package. But yes, sure, the Hurd way is bumpy. Just > > like Linux was when its was much less used. People seem to have > > completely forgotten that. Setting up Xorg used to be a nightmare there. > > The people who didn't know those times couldnt't have forgotten them. > Also, it's not the 90s any more :). > > -- > Richard Braun >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
On Fri, Jul 03, 2020 at 06:13:16PM +0200, Samuel Thibault wrote: > It's not "every" package. But yes, sure, the Hurd way is bumpy. Just > like Linux was when its was much less used. People seem to have > completely forgotten that. Setting up Xorg used to be a nightmare there. The people who didn't know those times couldnt't have forgotten them. Also, it's not the 90s any more :). -- Richard Braun
Re: Problems in Debian GNU/Hurd with Xorg and GCC
> I don't see why vesa wouldn't find a card, doesn't your BIOS provide >vesa? I don't find any related option in my BIOS config. > Possibly fbdev gets in the way, and it wouldn't work anyway, so > try to remove the xserver-xorg-video-fbdev package for a start. I removed It, but this doesn't solve the problem El vie., 3 jul. 2020 a las 18:14, Samuel Thibault () escribió: > Almudena Garcia, le ven. 03 juil. 2020 17:16:10 +0200, a ecrit: > > > IAs mentioned in the error message, see the log file (or post it here > so > > we can find out) > > > > I attach images of the log > > I don't see why vesa wouldn't find a card, doesn't your BIOS provide > vesa? Possibly fbdev gets in the way, and it wouldn't work anyway, so > try to remove the xserver-xorg-video-fbdev package for a start. > > Samuel >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 17:53:52 +0200, a ecrit: > > Concerning vim, git etc., use "apt-cache policy vim" etc to know the > > version you can install from unreleased, and install them this way: > > > > apt-get install vim=2:8.2.0716-2 > > Yes, I solved the problem with git at this way. But, anyways, it's necessary > to > solve the version conflicts in Debian GNU/Hurd repositories, without version > hacks. That'd be a way involved thing: it'd mean either adding the support into mini-dak, or making debian-ports migrate to dak instead of dak. Better just fix the bugs that prevent these packages from building normally and get installed normally. > If I show Debian GNU/Hurd to a friend, my friend can hate Hurd if he/she needs > to do this hack to every package ;) It's not "every" package. But yes, sure, the Hurd way is bumpy. Just like Linux was when its was much less used. People seem to have completely forgotten that. Setting up Xorg used to be a nightmare there. Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 17:16:10 +0200, a ecrit: > > IAs mentioned in the error message, see the log file (or post it here so > we can find out) > > I attach images of the log I don't see why vesa wouldn't find a card, doesn't your BIOS provide vesa? Possibly fbdev gets in the way, and it wouldn't work anyway, so try to remove the xserver-xorg-video-fbdev package for a start. Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
> Concerning vim, git etc., use "apt-cache policy vim" etc to know the > version you can install from unreleased, and install them this way: > > apt-get install vim=2:8.2.0716-2 Yes, I solved the problem with *git *at this way. But, anyways, it's necessary to solve the version conflicts in Debian GNU/Hurd repositories, without version hacks. If I show Debian GNU/Hurd to a friend, my friend can hate Hurd if he/she needs to do this hack to every package ;) El vie., 3 jul. 2020 a las 17:38, Samuel Thibault () escribió: > Samuel Thibault, le ven. 03 juil. 2020 17:37:15 +0200, a ecrit: > > Concerning vim, git etc., use "apt-cache policy vim" etc to know the > > version you can install from unreleased, and install them this way: > > > > apt-get install vim=2:8.2.0716-2 > > Also, could you turn what I scribbled above into text that could be > integrated on the proper webpage: > > https://www.debian.org/ports/hurd/hurd-install > > ? > > Thanks, > Samuel >
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Hi, Almudena. About the startx issue, takea look to this extract:"X.Org has been ported and all video cards, which it supports that do not require a kernel module or drm should work. You need to already be running the Hurd console and have repeaters setup as indicated in the previous section. For instance, check that echo $TERM prints hurd, and check that /dev/cons/kbd and /dev/cons/mouse exist. You need to run dpkg-reconfigure x11-common xserver-xorg-legacy to allow any user to start Xorg, because the X wrapper does not know about the Hurd and Mach consoles. You also need to create a /etc/X11/xorg.conf to enable the control-alt-backspace shortcut: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection It may happen that for some reason Xorg chooses a 16/9 resolution but a 4/3 desktop size. Blame Xorg, not the Hurd :) To avoid the issue, append this to /etc/X11/xorg.conf : Section "Screen" Identifier "myScreen" SubSection "Display" Virtual 1024 768 EndSubSection EndSection You will need several X packages. xorg, rxvt and a window manager: twm, icewm, openbox, ... are a good start. If you want X to get started at boot, you have to install a display manager. lightdm and gdm do not work yet, but xdm should just work fine. Finally, run startx /usr/bin/yourwm".Is taken from this Web Page:https://www.debian.org/ports/hurd/hurd-installWich can be considered a kind of "bible" for using Debian GNU/Hurd nowdays.Hope this advice helps you.Regards.Jose. --Enviado desde mi teléfono Android con mail.com 1 Mail. Por favor, disculpe mi brevedad.El 3/7/20, 16:25 Almudena Garcia escribió: Hi all: Today, I'm trying to install Debian GNU/Hurd in a new Thinkpad T60. I installed the latest image, from January 2020. But I found some problems in packaging and system running. In Xorg, when I try to execute startx, Xorg fails showing error No screens found. I was checking configurations, but I don't found the origin of this error. Additionally, I have some problems with packaging: - Running apt build-dep gnumach, I found a dependency conflict with libgcc1 package. - And git also requires an older version of git-man than the default version offered by apt. I found also similar problems in vim, and many other packages. I attach some images with the errors Can you solve these problems? Thanks
Re: Problems in Debian GNU/Hurd with Xorg and GCC
I've done all these steps. I'm running hurd-console, I configured the permissions using dpkg-reconfigure with this command, and even added ctrl_alt_bksp and screen configuration I'm following this guide, simply Xorg seems doesn't works in my machine https://www.debian.org/ports/hurd/hurd-install El vie., 3 jul. 2020 a las 17:45, Jose Luis Alarcon Sanchez (< jlalar...@ravemail.com>) escribió: > Hi, Almudena. > > About the startx issue, takea look to this extract: > > > "X.Org has been ported and all video cards, which it supports that do not > require a kernel module or drm should work. > > You need to already be running the Hurd console and have repeaters setup > as indicated in the previous section. For instance, check that echo $TERM > prints hurd, and check that /dev/cons/kbd and /dev/cons/mouse exist. > > You need to run dpkg-reconfigure x11-common xserver-xorg-legacy to allow > any user to start Xorg, because the X wrapper does not know about the Hurd > and Mach consoles. > > You also need to create a /etc/X11/xorg.conf to enable the > control-alt-backspace shortcut: > > Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option > "XkbOptions" "terminate:ctrl_alt_bksp" EndSection > > It may happen that for some reason Xorg chooses a 16/9 resolution but a > 4/3 desktop size. Blame Xorg, not the Hurd :) To avoid the issue, append > this to /etc/X11/xorg.conf : > > Section "Screen" Identifier "myScreen" SubSection "Display" Virtual 1024 > 768 EndSubSection EndSection > > You will need several X packages. xorg, rxvt and a window manager: twm, > icewm, openbox, ... are a good start. If you want X to get started at boot, > you have to install a display manager. lightdm and gdm do not work yet, but > xdm should just work fine. > > Finally, run startx /usr/bin/yourwm". > > Is taken from this Web Page: > > > https://www.debian.org/ports/hurd/hurd-install > > Wich can be considered a kind of "bible" for using Debian GNU/Hurd nowdays. > > Hope this advice helps you. > > Regards. > > Jose. > > -- > Enviado desde mi teléfono Android con mail.com 1 Mail. Por favor, > disculpe mi brevedad. > El 3/7/20, 16:25 Almudena Garcia escribió: > >> Hi all: >> >> Today, I'm trying to install Debian GNU/Hurd in a new Thinkpad T60. >> I installed the latest image, from January 2020. >> >> But I found some problems in packaging and system running. >> >> In Xorg, when I try to execute *startx, *Xorg fails showing error *No >> screens found.* >> I was checking configurations, but I don't found the origin of this >> error. >> >> Additionally, I have some problems with packaging: >> >> - Running *apt build-dep gnumach*, I found a dependency conflict with >> *libgcc1 >> *package. >> - And *git *also requires an older version of *git-man *than the default >> version offered by apt. >> I found also similar problems in *vim, *and many other packages. >> >> I attach some images with the errors >> >> Can you solve these problems? >> Thanks >> >>
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Samuel Thibault, le ven. 03 juil. 2020 17:37:15 +0200, a ecrit: > Concerning vim, git etc., use "apt-cache policy vim" etc to know the > version you can install from unreleased, and install them this way: > > apt-get install vim=2:8.2.0716-2 Also, could you turn what I scribbled above into text that could be integrated on the proper webpage: https://www.debian.org/ports/hurd/hurd-install ? Thanks, Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 17:10:06 +0200, a ecrit: > > Again, do you have properly set up the apt sources, notably the > > unreleased one? There are installable versions of these there. > > I attach my sources.list . I have all repositories, except the snapshot Ok so probably just first remove libgcc1, or if that entails removing a lot of packages, tell apt to upgrade gcc-9 at the same time you remove libgcc1: apt-get install gcc-9 libgcc1- Concerning vim, git etc., use "apt-cache policy vim" etc to know the version you can install from unreleased, and install them this way: apt-get install vim=2:8.2.0716-2 Samuel
Re: Problems in Debian GNU/Hurd with Xorg and GCC
Almudena Garcia, le ven. 03 juil. 2020 16:25:17 +0200, a ecrit: > I was checking configurations, but I don't found the origin of this error. As mentioned in the error message, see the log file (or post it here so we can find out) > - Running apt build-dep gnumach, I found a dependency conflict with libgcc1 > package. Do you have properly network-based apt sources correctly configured? 9.3.0-13 packages are available there. It seems libgcc1 is no longer in the new gcc-9 package, apt is supposed to determine that it should remove it. Apparently it doesn't, but you can remove it by hand. > - And git also requires an older version of git-man than the default version > offered by apt. > I found also similar problems in vim, and many other packages. Again, do you have properly set up the apt sources, notably the unreleased one? There are installable versions of these there. Samuel
gnumach: [PATCH] - irq as a mach device
Hi folks,
As discussed on IRC, I am working on refactoring IRQ handling so that
it can be opened as a mach device. However, I need to clean up the existing
irq code.
I am trying to make this more modular, so I have moved the irq
masking/unmasking to pic.c
and created an arch-specific irq.h and irq.c to hold the "line" information.
I have tried to refactor the RPCs but I'm not sure how to make it a
fully-fledged "irq" mach device.
Can someone please review this patch? I'm not sure how much of it can be
applied as-is at present,
but it does compile and run correctly on existing in-kernel disk drivers.
However, as expected, it breaks netdde in its current state because the RPC
calls are different.
It seems the "disable" part of the device_intr_enable RPC is not needed so I
have made it "enable" only.
Damien
>From 3d0320624cff643b5ba66c39f340253a3ca210ab Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sat, 27 Jun 2020 22:57:51 +1000
Subject: [PATCH] irq: Refactor interrupt handling as a mach device
---
Makefrag.am | 4 +-
device/ds_routines.c | 62 +++
device/ds_routines.h | 3 -
device/intr.h| 37
device/{intr.c => irq.c} | 289 +++
device/irq.h | 48 +
i386/Makefrag.am | 2 +
i386/i386/irq.c | 30
i386/i386/irq.h | 13 ++
i386/i386/pic.c | 54 ++
i386/i386/pic.h | 2 +
i386/i386at/conf.c | 8 +
include/device/device.defs | 16 +-
include/device/notify.defs | 2 +-
include/device/notify.h | 2 +-
kern/startup.c | 2 +-
linux/dev/arch/i386/kernel/irq.c | 53 +-
17 files changed, 341 insertions(+), 286 deletions(-)
delete mode 100644 device/intr.h
rename device/{intr.c => irq.c} (51%)
create mode 100644 device/irq.h
create mode 100644 i386/i386/irq.c
create mode 100644 i386/i386/irq.h
diff --git a/Makefrag.am b/Makefrag.am
index 73508350..d8147a40 100644
--- a/Makefrag.am
+++ b/Makefrag.am
@@ -313,8 +313,8 @@ libkernel_a_SOURCES += \
device/ds_routines.h \
device/if_ether.h \
device/if_hdr.h \
- device/intr.c \
- device/intr.h \
+ device/irq.c \
+ device/irq.h \
device/io_req.h \
device/net_io.c \
device/net_io.h \
diff --git a/device/ds_routines.c b/device/ds_routines.c
index 13c9a63e..7f906adc 100644
--- a/device/ds_routines.c
+++ b/device/ds_routines.c
@@ -92,9 +92,9 @@
#include
#include
#include
-#include
#include
+#include
#ifdef LINUX_DEV
extern struct device_emulation_ops linux_block_emulation_ops;
@@ -321,44 +321,36 @@ ds_device_map (device_t dev, vm_prot_t prot, vm_offset_t offset,
/* TODO: missing deregister support */
io_return_t
-ds_device_intr_register (ipc_port_t master_port, int line,
- int id, int flags, ipc_port_t receive_port)
+ds_device_intr_register (ipc_port_t master_port, int id,
+ int flags, ipc_port_t receive_port)
{
-#ifdef MACH_XEN
- return D_INVALID_OPERATION;
-#else /* MACH_XEN */
- io_return_t ret;
+ kern_return_t err;
+ struct irqdev *dev = &irqtab;
/* Open must be called on the master device port. */
if (master_port != master_device_port)
return D_INVALID_OPERATION;
- /* XXX: move to arch-specific */
- if (line < 0 || line >= 16)
-return D_INVALID_OPERATION;
-
- user_intr_t *user_intr = insert_intr_entry (line, receive_port);
- if (!user_intr)
-return D_NO_MEMORY;
// TODO The original port should be replaced
- // when the same device driver calls it again,
+ // when the same device driver calls it again,
// in order to handle the case that the device driver crashes and restarts.
- ret = install_user_intr_handler (line, flags, user_intr);
-
- if (ret == 0)
- {
-/* If the port is installed successfully, increase its reference by 1.
- * Thus, the port won't be destroyed after its task is terminated. */
-ip_reference (receive_port);
-
-/* For now netdde calls device_intr_enable once after registration. Assume
- * it does so for now. When we move to IRQ acknowledgment convention we will
- * change this. */
-__disable_irq (line);
- }
-
- return ret;
-#endif /* MACH_XEN */
+ user_intr_t *e = insert_intr_entry (dev, id, receive_port);
+ if (!e)
+return D_NO_MEMORY;
+
+ err = install_user_intr_handler (dev, id, flags, e);
+ if (err == D_SUCCESS)
+{
+ /* If the port is installed successfully, increase its reference by 1.
+ * Thus, the port won't be destroyed after its task is terminated. */
+ ip_reference (receive_port);
+
+ /* For now netdde calls device_intr_enable once after registration. Assume
+ * it does so for now. When we move to IRQ acknowledgment convention we will
+ * change this. */
+ irq_disable (dev->irq[e->id]);
+}
+ return err;
}
boolean_t
@@ -1842,16
