Re: kern/42772 -- pthread issue with fork()
On 3/24/10 9:13 PM, Joerg Sonnenberger wrote: The point is that you don't really get that. Consider mutexes currently hold by a different thread in the original program. May I strongly advise you to first identify exactly where Ruby is failing and based on that let us decide how it can be fixed. I'll take a look into what is going on there. Ruby 1.9 is rather... complicated internally, and NetBSD is not (currently) a supported OS. I know their thread code works as-is on linux, solaris, and macos, so whatever they are doing is safe from their point of view. --Michael
Re: config(5) break down
On Thu, Mar 25, 2010 at 09:09:32AM +, David Holland wrote: On Thu, Mar 25, 2010 at 12:46:10PM +0900, Masao Uebayashi wrote: % grep ':.*,' sys/conf/files | wc -l 86 And? I don't understand your point. There are a lot more than 86 entities in sys/conf/files. There are many instances where modules have multiple dependencies. Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: config(5) break down
On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote: % grep ':.*,' sys/conf/files | wc -l 86 And? I don't understand your point. There are a lot more than 86 entities in sys/conf/files. There are many instances where modules have multiple dependencies. And? I still don't understand your point. -- David A. Holland dholl...@netbsd.org
Re: Using proplist ioctl's from within the kernel
jeanyves.mig...@free.fr said: There should be some way to serialize/deserialize prop/plistref objects within the kernel, but I never found a solution. I suppose you will have to dig deeper than I did :/ 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. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: Using proplist ioctl's from within the kernel
On Thu, 25 Mar 2010, Matthias Drochner wrote: jeanyves.mig...@free.fr said: There should be some way to serialize/deserialize prop/plistref objects within the kernel, but I never found a solution. I suppose you will have to dig deeper than I did :/ 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? - | 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
On Fri, Mar 26, 2010 at 12:41 PM, matthew green m...@eterna.com.au wrote: On Fri, Mar 26, 2010 at 6:49 AM, David Holland dholland-t...@netbsd.org wrote: On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote: % grep ':.*,' sys/conf/files | wc -l 86 And? I don't understand your point. There are a lot more than 86 entities in sys/conf/files. There are many instances where modules have multiple dependencies. And? I still don't understand your point. OK, then I may be misunderstanding what you meant by diamonds. But anyway, never mind. I give up convincing you because this seems to be never going to be constructive. I see no benefit in convincing you. please keep going. i am yet to see any benefit to your ideas in this thread. you've not given any good reason for breaking up files*. To manage dependency nicely. When a module A dpend on B, you write define A: B, where B has to be already define'ed in the current syntax. We're managing such ordering by hand in sys/conf/files. By splitting files use include, we don't need to manage such a mess by hand. David Holland already understood this: http://mail-index.netbsd.org/tech-kern/2010/03/11/msg007633.html So we have already agreed that split has some benefit. The point is, my split+include way doesn't need any syntax change. 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. Masao
re: config(5) break down
To manage dependency nicely. When a module A dpend on B, you write define A: B, where B has to be already define'ed in the current syntax. We're managing such ordering by hand in sys/conf/files. By splitting files use include, we don't need to manage such a mess by hand. David Holland already understood this: http://mail-index.netbsd.org/tech-kern/2010/03/11/msg007633.html So we have already agreed that split has some benefit. The point is, my split+include way doesn't need any syntax change. the above mail doesn't agree with splitting files* for every device. it agrees that some better ideas might be useful. i like your ideas about using define better, and being more clear about dependancies, but why do you need so many files? (given the above url, i like the (2) option for the split.) i have no idea how splitting them makes the ordering no longer by hand. the ordering is still explicitly done by hand, it is just done in a bunch of files now, using more lines than would previously be required. eg, instead of all the drivers in files.pci being how they are today, they each get to have to include all the PCI definitions, and other ones. each driver / module file will have a large list of includes, all managed by hand. seems ugly and inefficient to me. 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 read this and i look at the devfs thread and i am not sure if i want to laugh or cry. .mrg.
