Re: config(5) break down
On Fri Mar 26 2010 at 13:25:43 +0900, Masao Uebayashi wrote:
syntax. I spent a whole weekend to read sys/conf/files, ioconf.c, and
module stubs in sys/dev/usb/uaudio.c. I wasted a whole weekend. I've
This patch should work and make it easier. No, it doesn't solve
dependencies, but gets developers at least halfway there without having
to waste weekends (with code). Unfortunately I can't test, since I
forgot to buy a usb audio device from Akihabara ;)
Index: dev/usb/uaudio.c
===
RCS file: /cvsroot/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.117
diff -p -u -r1.117 uaudio.c
--- dev/usb/uaudio.c12 Nov 2009 19:50:01 - 1.117
+++ dev/usb/uaudio.c26 Mar 2010 06:11:39 -
@@ -3065,67 +3065,21 @@ uaudio_set_speed(struct uaudio_softc *sc
MODULE(MODULE_CLASS_DRIVER, uaudio, NULL);
-static const struct cfiattrdata audiobuscf_iattrdata = {
- audiobus, 0, { { NULL, NULL, 0 }, }
-};
-static const struct cfiattrdata * const uaudio_attrs[] = {
- audiobuscf_iattrdata, NULL
-};
-CFDRIVER_DECL(uaudio, DV_DULL, uaudio_attrs);
-extern struct cfattach uaudio_ca;
-static int uaudioloc[6/*USBIFIFCF_NLOCS*/] = {
- -1/*USBIFIFCF_PORT_DEFAULT*/,
- -1/*USBIFIFCF_CONFIGURATION_DEFAULT*/,
- -1/*USBIFIFCF_INTERFACE_DEFAULT*/,
- -1/*USBIFIFCF_VENDOR_DEFAULT*/,
- -1/*USBIFIFCF_PRODUCT_DEFAULT*/,
- -1/*USBIFIFCF_RELEASE_DEFAULT*/};
-static struct cfparent uhubparent = {
- usbifif, NULL, DVUNIT_ANY
-};
-static struct cfdata uaudio_cfdata[] = {
- {
- .cf_name = uaudio,
- .cf_atname = uaudio,
- .cf_unit = 0,
- .cf_fstate = FSTATE_STAR,
- .cf_loc = uaudioloc,
- .cf_flags = 0,
- .cf_pspec = uhubparent,
- },
- { NULL }
-};
+#include ioconf.c
static int
uaudio_modcmd(modcmd_t cmd, void *arg)
{
- int err;
switch (cmd) {
case MODULE_CMD_INIT:
- err = config_cfdriver_attach(uaudio_cd);
- if (err) {
- return err;
- }
- err = config_cfattach_attach(uaudio, uaudio_ca);
- if (err) {
- config_cfdriver_detach(uaudio_cd);
- return err;
- }
- err = config_cfdata_attach(uaudio_cfdata, 1);
- if (err) {
- config_cfattach_detach(uaudio, uaudio_ca);
- config_cfdriver_detach(uaudio_cd);
- return err;
- }
- return 0;
+ return config_init_component(cfdriver_comp_uaudio,
+ cfattach_comp_uaudio, cfdata_uaudio);
+
case MODULE_CMD_FINI:
- err = config_cfdata_detach(uaudio_cfdata);
- if (err)
- return err;
- config_cfattach_detach(uaudio, uaudio_ca);
- config_cfdriver_detach(uaudio_cd);
- return 0;
+ return config_fini_component(cfdriver_comp_uaudio,
+ cfattach_comp_uaudio, cfdata_uaudio);
+
default:
return ENOTTY;
}
Index: modules/uaudio/Makefile
===
RCS file: /cvsroot/src/sys/modules/uaudio/Makefile,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile
--- modules/uaudio/Makefile 28 Jun 2008 09:14:56 - 1.1
+++ modules/uaudio/Makefile 26 Mar 2010 06:11:39 -
@@ -5,6 +5,7 @@
.PATH: ${S}/dev/usb
KMOD= uaudio
+IOCONF=UAUDIO.ioconf
SRCS= uaudio.c
.include bsd.kmodule.mk
Index: modules/uaudio/UAUDIO.ioconf
===
RCS file: modules/uaudio/UAUDIO.ioconf
diff -N modules/uaudio/UAUDIO.ioconf
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modules/uaudio/UAUDIO.ioconf26 Mar 2010 06:11:39 -
@@ -0,0 +1,12 @@
+# $NetBSD$
+#
+
+ioconf uaudio
+
+include conf/files
+include dev/usb/files.usb
+
+pseudo-root uhub*
+
+# USB audio
+uaudio* at uhub? port ? configuration ?
Re: config(5) break down
I do know you've wasted longer time than me. ;) Actually what I need
are host controller drivers. Just picked up uaudio(4) to learn things
because it looked odder than others. But thanks for the patch.
On Fri, Mar 26, 2010 at 3:14 PM, Antti Kantee po...@cs.hut.fi wrote:
(snip)
Index: modules/uaudio/Makefile
===
RCS file: /cvsroot/src/sys/modules/uaudio/Makefile,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile
--- modules/uaudio/Makefile 28 Jun 2008 09:14:56 - 1.1
+++ modules/uaudio/Makefile 26 Mar 2010 06:11:39 -
@@ -5,6 +5,7 @@
.PATH: ${S}/dev/usb
KMOD= uaudio
+IOCONF= UAUDIO.ioconf
SRCS= uaudio.c
.include bsd.kmodule.mk
Surely this intermediate makefile and directory can go away, eventually.
Index: modules/uaudio/UAUDIO.ioconf
===
RCS file: modules/uaudio/UAUDIO.ioconf
diff -N modules/uaudio/UAUDIO.ioconf
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modules/uaudio/UAUDIO.ioconf 26 Mar 2010 06:11:39 -
@@ -0,0 +1,12 @@
+# $NetBSD$
+#
+
+ioconf uaudio
+
+include conf/files
+include dev/usb/files.usb
+
+pseudo-root uhub*
+
+# USB audio
+uaudio* at uhub? port ? configuration ?
I see this is toward the direction I'm going too. We can teach
config(1) to analyze dependency generate the necessary stub for
modules, including the default cfdata part, *in theory*.
Masao
Re: Using proplist ioctl's from within the kernel
On Thu, 25 Mar 2010, Paul Goyette wrote: So would it be appropriate for me to expose sysmon_envsys's global mutex and its device list in order for acpi_apm to scan for battery sensors and A/C adapters? I think better to not expose subsystem internals.. but can you split the sysmon_envsys API into functionality and userland interface so that a kernel module can call the functionality directly? Vaguely (ie without examining your needs at all) I'm thinking of something like sys_bind() and do_sys_bind() from uipc_syscalls.c though that doesn't handle plists. I used a plist wrapper in bthub.c as its easier to write a function that handles a dictionary, perhaps that method would be useful? iain
Problems with radeondrm
Hello, I'm running NetBSD/i386 5.99.24 on an MSI board with an ATI Radeon 2400 XT plugged in. To have 2d acceleration and XVideo, I load radeondrm.kmod at boottime. It usually works, but after restarting X sufficiently often, it suddenly stops; that is, either display is corrupted, or X does not find DRI support anymore. There are a few pecularities: From dmesg (which is also attached): agp0 at pchb0: can't find internal VGA device config space ... ppb0: unsupported PCI Express version ... vga1: WARNING: ignoring 64-bit BAR @ 0x10 vga1: WARNING: ignoring 64-bit BAR @ 0x18 and, after each restart of X: info: [drm] Setting GART location based on new memory map info: [drm] Loading RV610 Microcode info: [drm] Resetting GPU info: [drm] writeback test failed deadbeef Usually, after a while I get a message that something failed; I think it has to do with the memory map, but unfortunately I can't reproduce it at the moment. Trying to reproduce the problem, I tried to fill up RAM and make the system use swap. Indeed, radeondrm then got detached: radeondrm0: detached Attached is an Xorg.0.log from after the problem occured. The following lines seem suspicious to me: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' ... (II) RADEONHD(0): [drm] failure adding irq handler, there is a device already using that irq [drm] falling back to irq-free operation One time, X would crash, leaving 20 lines saying (EE) RADEONHD(0): RHDDRMCPBuffer: drmDMA returned -6 It would be very nice if someone could look into this. Assuming that perhaps more info is needed: does it suffice to sysctl -w hw.dri.debug=1, or would I have to compile a kernel with DRM_DEBUG? Many TIA, Dennis den Brok Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.99.24 (GENERIC) #0: Thu Mar 18 17:34:26 UTC 2010 bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20100318Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC total memory = 2047 MB avail memory = 2000 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 MICRO-STAR INTERNATIONAL CO.,LTD MS-7519 (1.0) mainbus0 (root) cpu0 at mainbus0 apid 0: Intel 686-class, 2673MHz, id 0x10676 cpu1 at mainbus0 apid 1: Intel 686-class, 2673MHz, id 0x10676 ioapic0 at mainbus0 apid 2: pa 0xfec0, version 20, 24 pins acpi0 at mainbus0: Intel ACPICA 20090730 acpi0: X/RSDT: OemId 7519MS,A7519200,20080730, AslId MSFT,0097 acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present timecounter: Timecounter ACPI-Fast frequency 3579545 Hz quality 1000 ACPI-Fast 24-bit timer attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0 pcppi1 at acpi0 (SPKR, PNP0800): io 0x61 midi0 at pcppi1: PC speaker sysbeep0 at pcppi1 npx1 at acpi0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 UAR1 (PNP0501) at acpi0 not configured hpet0 at acpi0 (HPET, PNP0103): mem 0xfed0-0xfed003ff timecounter: Timecounter hpet0 frequency 14318179 Hz quality 2000 pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1 pckbc2 at acpi0 (PS2M, PNP0F03) (aux port): irq 12 acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button apm0 at acpi0: Power Management spec V1.2 attimer1: attached to pcppi1 pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x2e20 (rev. 0x03) agp0 at pchb0: can't find internal VGA device config space ppb0 at pci0 dev 1 function 0: vendor 0x8086 product 0x2e21 (rev. 0x03) ppb0: unsupported PCI Express version pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled, rd/line, wr/inv ok vga1 at pci1 dev 0 function 0: vendor 0x1002 product 0x94c1 (rev. 0x00) vga1: WARNING: ignoring 64-bit BAR @ 0x10 vga1: WARNING: ignoring 64-bit BAR @ 0x18 wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 wsmux1: connecting to wsdisplay0 drm at vga1 not configured hdaudio0 at pci1 dev 0 function 1: HD Audio Controller hdaudio0: interrupting at ioapic0 pin 17 hdafg0 at hdaudio0 vendor 0x1002 product 0xAA01 nid 0x01 (firmware configuration) hdafg0: DAC0:02, Digital Digital Other Out: Jack (Unknown, 03) hdafg0: 2ch/0ch 48000Hz 16/16 audio0 at hdafg0: half duplex, playback uhci0 at pci0 dev 26 function 0: vendor 0x8086 product 0x3a37 (rev. 0x00) uhci0: interrupting at ioapic0 pin 16 usb0 at uhci0: USB
Re: kernel module for pad(4)
On Thu, 25 Mar 2010 23:14:47 +0100 Zafer Aydogan za...@aydogan.de wrote: 2010/3/24 Adam Hoka adam.h...@gmail.com: Hi! Anyone can have a look at this and/or test it? http://www.netbsd.org/~ahoka/patches/sys_modules_pad.tar.gz This is my first try at making a module, so any comments are welcomed. :-) Cheers, Adam -- NetBSD - Simplicity is prerequisite for reliability compiling and installing went fine. but trying to load pad fails: # modload pad modload: File exists Mar 25 23:11:11 desktop /netbsd: WARNING: module error: modcmd function returned error 17 for `pad' do i need to tweak something ? zafer. You have to remove pad from the kernel config to be loaded as a module. -- NetBSD - Simplicity is prerequisite for reliability
Re: Using proplist ioctl's from within the kernel
On Fri, 26 Mar 2010, haad wrote: I think it should be avoided at all costs. With proplists, you give up type safety and you create a lot of overhead. This is acceptable for kernel-user interfaces in some cases but not within the kernel. So would it be appropriate for me to expose sysmon_envsys's global mutex and its device list in order for acpi_apm to scan for battery sensors and A/C adapters? This is wrong and should be avoided IMHO. Well, as it turns out, both the global mutex and the device list are already exposed, so it is a rather trivial task for acpi_apm.c to scan the device list. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: config(5) break down
Date:Fri, 26 Mar 2010 14:52:09 +0900 From:Masao Uebayashi uebay...@gmail.com Message-ID: 70f62c5e1003252252h6e5ba506xfafceb76f854b...@mail.gmail.com | You need to include dependency. You don't need to care the order of | include lines. This is pretty much same as C headers including its | dependency vs. not include in *.h but managing the order in *.c. But C include files are a disaster - a huge mess inherited from history. No-one sane would deliberately design that as a solution for anything. As a user of the things I'd much rather all that just happened automatically, when I use fopen() if the compiler needs stdio.h, it should just go and get stdio.h - it's absurd to make me explicitly say I need it. For C, because of the nature of the world 30+ years ago, and development since, there's nothing we can do about it. But copying that as if it was a great system would be absurd. | Same as pkgsrc buildlink3.mk including its dependency too. No, those are totally different - those are different files because they're managed separately, as a part of each package - the maintainer of graphics/jpeg looks after jpeg/builink3.mk and makes it does whatever is necessary to correctly link whatever -ljpeg required. Those are separate files, not because separate files is a good thing, but because the management of anything different would be a nightmare. If your reason for lots of little conf files was because there are lots of little independent projects, each producing and looking after their own little piece of the puzzle, that would be something that might reach agreement (if it were correct). But the reason seems to just be this dependency ordering thing - which it looks like you're planning on solving it the .h file way (with each file including anything it needs, then added protection against including anything more than once, and ... which is all just a huge mess). That's not the way to fix this problem. If it has become serious enough that doing it manually is no longer sensible, then just fix config to remove the ordering rule - I don't think there's any good reason for it (and you certainly are not proposing making it stronger). Making config do a two pass parse of the config file(s) would be an afternoon's work - it was never done that way because manual ordering started out being so simple to do, that the afternoon's work was never justified. Then, as each new entry was added, manually ordering that new entry was always less than that afternoon's work. Almost certainly the sum of all of that effort is (now) greater than the effort it would have taken to fix config, but no-one has ever really fallen against it hard enough that they could justify spending the afternoon to fix it. Maybe that's changed now - certainly I suspect that there's been more time spent on this discussion than it would take to have just fixed config in the first place. | Having a | single *.conf per module is natural. As natural as userland commands | and libraries have a single Makefile for each. This one is a different argument (and as I remember this is more where you started, before you got onto that ordering nonsense), this relates more to management, and is much more reasonable. However, since I'm a believer in the single module kernel, that also makes me a believer in the single files.conf file - and for people like me, following this line of reasoning, you'd agree right? (Regardless of whether or not you agree with the single module approach). | I'm not saying changing syntax is bad. My complaint is that David | Holland is suggesting things without understanding the existing | syntax. I spent a whole weekend to read sys/conf/files, ioconf.c, and | module stubs in sys/dev/usb/uaudio.c. I wasted a whole weekend. I've | been wasting more time to convince David Holland who has never | bothered to understand the existing syntax. I'm pretty sure he understands the existing syntax. I am pretty sure that I understand the existing syntax as well. The syntax of what is in the file(s) is pretty much an orthagonal issue - I certainly agree that the syntax could be improved, but I don't see that having almost any bearing upon the multiple files issue - it doesn't need to change to allow a 2 pass parser to remove any ordering relationship on the config file lines, and it can change, whether we have one config file (as it once was), a dozen or whatever it is now, or a hundred or more (your proposal). When mrg said he wanted to cry, or laugh, at your message, I suspect it was because if there had been a zillion little files, the weekend you spent would probably have been at least a week And lastly, it isn't just David you need to convince - that only one person is arguing with you doesn't mean only one person believes what he is saying (and that only you are arguing for your proposal doesn't mean that only you believe that is the
Re: bus_space_physload(9)
On Fri, 26 Mar 2010, Masao Uebayashi wrote: This is the list of updated functions: /* register device memory as part of system memory */ void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr, bus_size_t size); void bus_space_physunload(void *physseg); /* register device region as user-mappable managed region */ void *bus_space_physload_device(bus_space_tag_t space, bus_addr_t addr, bus_size_t size, int prot, int flags); void bus_space_physunload_device(void *physseg); I've not considered the memory one very much. It needs more thought... I'm not convinced that handing device pages off to the VM subsystem is the correct approcach. That makes the assumption that all physical address space is equivalent and you don't have to worry about caches or sideffects, which the MMU needs to be informed about in some architectures or you get all sorts of nasty effects such as data corruption or data faults. I think a better design woult be to have the device driver provide a routine UVM calls to enter and remove individual pages from the pmap. That way you can do device or specific things such as setting the non-cacheable or write-only bit on the TTE. Eduardo
Re: kernel module for pad(4)
2010/3/26 Adam Hoka adam.h...@gmail.com: On Thu, 25 Mar 2010 23:14:47 +0100 Zafer Aydogan za...@aydogan.de wrote: 2010/3/24 Adam Hoka adam.h...@gmail.com: Hi! Anyone can have a look at this and/or test it? http://www.netbsd.org/~ahoka/patches/sys_modules_pad.tar.gz This is my first try at making a module, so any comments are welcomed. :-) Cheers, Adam -- NetBSD - Simplicity is prerequisite for reliability compiling and installing went fine. but trying to load pad fails: # modload pad modload: File exists Mar 25 23:11:11 desktop /netbsd: WARNING: module error: modcmd function returned error 17 for `pad' do i need to tweak something ? zafer. You have to remove pad from the kernel config to be loaded as a module. -- NetBSD - Simplicity is prerequisite for reliability I did and now it works fine. desktop# modload pad desktop# modstat NAME CLASS SOURCE REFS SIZE REQUIRES bpf driver builtin0 -- compat misc builtin0 -- coredump misc filesys1 3064 - exec_elf32 misc filesys0 7163 coredump exec_script misc filesys0 1187 - ffs vfsboot 0 165969 - kernfs vfsfilesys0 10969- pad driver filesys0 4581 - procfs vfsfilesys0 28006- ptyfsvfsfilesys0 8814 - secmodel_bsd44 secmodel builtin0 -suser,securelevel securelevel secmodel builtin1 -- susersecmodel builtin1 -- tmpfsvfsfilesys0 18345- desktop# Thanks a lot, Zafer.
Re: bus_space_physload(9)
Hi, On Fri, Mar 26, 2010 at 04:25:19PM +, Eduardo Horvath wrote: On Fri, 26 Mar 2010, Masao Uebayashi wrote: This is the list of updated functions: /* register device memory as part of system memory */ void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr, bus_size_t size); void bus_space_physunload(void *physseg); /* register device region as user-mappable managed region */ void *bus_space_physload_device(bus_space_tag_t space, bus_addr_t addr, bus_size_t size, int prot, int flags); void bus_space_physunload_device(void *physseg); I've not considered the memory one very much. It needs more thought... I'm not convinced that handing device pages off to the VM subsystem is the correct approcach. That makes the assumption that all physical address space is equivalent and you don't have to worry about caches or sideffects, which the MMU needs to be informed about in some architectures or you get all sorts of nasty effects such as data corruption or data faults. The point is that device drivers call bus_space_physload_device(9) only for regions that are potentically mapped as cache enabled or other effects. In that case the registered regions are treated as managed; UVM allocates a context to keep track of where pages are mapped and how. pmap(9) keeps a state in struct vm_page_md (conventionally). So UVM will allocate struct vm_page_md hash to manage only mapped pages. I assume device regions have uniform charasteristic. (I'm looking for a counter example.) I think a better design woult be to have the device driver provide a routine UVM calls to enter and remove individual pages from the pmap. That way you can do device or specific things such as setting the non-cacheable or write-only bit on the TTE. Do you mean you expose MMU knowledge to device drivers? How does your idea look in pseudo code? I don't want to give device drivers too much freedom. Real devices are connected via buses. It's odd that those drivers have to know things beyond those physical connections. (I'll learn TTE then reply again.) Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
re: bus_space_physload(9)
(I'll learn TTE then reply again.) for everyone: TTE is sparc64 for PTE. translation table entry. defined in sparc64/include/pte.h :-)
