Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 10:31:25PM -0800, David Schultz wrote: Note that I was only suggesting this patch be committed to -current for purposes of finding out what these applications are, and fixing them as appropriate. Then how about wrapping the warning in an #ifdef, so people who want to find inappropriate uses of rand() can do so for as long as they want, and everyone else who uses -CURRENT is not affected? That sounds fine to me. Kris msg52544/pgp0.pgp Description: PGP signature
Re: The cbus driver for pc98
In message: [EMAIL PROTECTED] Takahashi Yoshihiro [EMAIL PROTECTED] writes: : I have made the cbus driver for pc98 based on i386 isa driver. This : completely removes that PC98 depends on isa driver and also corrects : directory layouts (pc98/i386 - pc98/pc98 and pc98/pc98 - pc98/cbus). : : The full patch can get from : http://home.jp.FreeBSD.org/~nyan/patches/cbus.diff.gz : : Soeren, please review the ata part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz : : Warner, please review the oldcard part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-pccard.diff.gz : : : If it has no problem, I'll commit after required repository copy. Please excuse my tardiness in replying to this review request. I've just finished a large release at work that was consuming much of my time. I do not like this. It seems to take too many files and just do a simple s/isa/cbus/g on them. However, I'm not sure that we want to do that with so many files when the majority of them are very close to being able to just add a second module line. I think it would be better to implement cbus as an 'isa bus subclass'. cbus is an isa-like bus in many respects from a programming point of view. Copying everything is not the right way to approach this problem, imho. It would be better if the cbus bus implemented the isa routines and accepted that 'isa' is a bit if a misnomer. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Takahashi Yoshihiro [EMAIL PROTECTED] writes: : I have made the cbus driver for pc98 based on i386 isa driver. This : completely removes that PC98 depends on isa driver and also corrects : directory layouts (pc98/i386 - pc98/pc98 and pc98/pc98 - pc98/cbus). : : The full patch can get from : http://home.jp.FreeBSD.org/~nyan/patches/cbus.diff.gz : : Soeren, please review the ata part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz : : Warner, please review the oldcard part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-pccard.diff.gz : : : If it has no problem, I'll commit after required repository copy. Please excuse my tardiness in replying to this review request. I've just finished a large release at work that was consuming much of my time. I do not like this. It seems to take too many files and just do a simple s/isa/cbus/g on them. However, I'm not sure that we want to do that with so many files when the majority of them are very close to being able to just add a second module line. I think it would be better to implement cbus as an 'isa bus subclass'. cbus is an isa-like bus in many respects from a programming point of view. Copying everything is not the right way to approach this problem, imho. It would be better if the cbus bus implemented the isa routines and accepted that 'isa' is a bit if a misnomer. I can understand if you do not like to call your cbus hardware ISA devices, but also consider that on most pc-at hardware there are no ISA devices either. Things like the floppy controller, keyboard controller, counter/timer, rtc, etc etc are all on motherboard busses. Many are on things like X-bus, v-link, or other custom quick and dirty host busses. If we started i386/x-bus/* and i386/v-link/* etc then things would get ugly very quickly. Personally, I would rather live with #ifdef PC98 than to have a duplicate set of isa/* and i386/* files that are nearly identical except for include file paths, #ifdef PC98 and s/isa/cbus/. I'm sure there are other ways to improve the situation without having to resort to this mass duplication of code. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: question on profiling code
Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100, Bruce Evans said words to the effect of; On Sun, 16 Feb 2003, Julian Elischer wrote: In addupc_intr, if the increment cannot be done immediatly, the addres to increment the count for is stored and the increment is done later at ast or userret() time... Note that cannot be done immediatly is always except on sparc64's under FreeBSD, since incrementing the counter immediately is only implemented on sparc64's. is there any reason that the address of the PC needs to be stored? why is the address from the frame at that time not useable? is it because the PC in the return frame may be hacked up for signals? That's was good a reason as any. I think the next return to user mode is to the signal handler's context (if there is a signal to be handled). It would be wrong to use the signal handler's pc. Also, ast() doesn't have access to the frame, and there is no macro like CLKF_PC() for general frames. This probably doesn't matter much, since signals are rare and the hitting on the signal handler's pc would be perfectly correct if the profiling interrupt occurred an instant later. There are macros for accessing trapframes, like the ones for clockframe, TRAPF_PC etc. Now there is a stronger reason: clock interrupt handling is fast, so it normally returns to user mode without going near ast(), and the counter is not updated until the next non-fast interrupt or syscall. In freebsd fast interrupts do handle asts, on i386 they return through doreti (you may consider this a bug and have removed it in your version). I see no reason not to just use the pc in the trapframe passed to ast, even in the case of signals they won't be posted until after addupc_task is called. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
--En cette belle journée du dimanche 16 février 2003 16:08 -0600 -- Juli Mallett [EMAIL PROTECTED] écrivait : | FreeBSD has special great evil triggers which will import things into | //depot/vendor/freebsd/src/... for example, and then we just branch off | of there, and integ -b as needed. | | :) Are these triggers top secret, or would it be possible to share them with the rest of us ? -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
* De: Mathieu Arnold [EMAIL PROTECTED] [ Data: 2003-02-17 ] [ Subjecte: Re: Local repo: Perforce/CVS integration ] --En cette belle journée du dimanche 16 février 2003 16:08 -0600 -- Juli Mallett [EMAIL PROTECTED] écrivait : | FreeBSD has special great evil triggers which will import things into | //depot/vendor/freebsd/src/... for example, and then we just branch off | of there, and integ -b as needed. | | :) Are these triggers top secret, or would it be possible to share them with the rest of us ? When i said triggers above, I was thinking of something else, what I was referring to is actually a periodic (or manually kicked off) job to import things to the vendor area. -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Local repo: Perforce/CVS integration
--En cette belle journée du lundi 17 février 2003 01:21 -0600 -- Juli Mallett [EMAIL PROTECTED] écrivait : | * De: Mathieu Arnold [EMAIL PROTECTED] [ Data: 2003-02-17 ] | [ Subjecte: Re: Local repo: Perforce/CVS integration ] | --En cette belle journée du dimanche 16 février 2003 16:08 -0600 | -- Juli Mallett [EMAIL PROTECTED] écrivait : | | FreeBSD has special great evil triggers which will import things into | | //depot/vendor/freebsd/src/... for example, and then we just branch off | | of there, and integ -b as needed. | | | | :) | | Are these triggers top secret, or would it be possible to share them with | the rest of us ? | | When i said triggers above, I was thinking of something else, what I was | referring to is actually a periodic (or manually kicked off) job to import | things to the vendor area. This does not answer to the question :) -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI thermal panics ThinkPad 600X
Ruslan Ermilov wrote: --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2003 at 10:24:57AM -0800, David O'Brien wrote: On Sun, Feb 16, 2003 at 07:55:49PM +0200, Ruslan Ermilov wrote: Don't cross post current and developers. =20 The developers charter says it's for internal management i.e. how we manage the project and not for discussing code issues. It's badly nam= ed, we should have called it something like members or admin. =20 I must disagree. This message equally applies -current as well as -developers; =20 It doesn't matter what you think -- this is our written down rules. Please obey them. If you want to target both lists, sent the message out twice -- once to each list. =20 OK, I stand corrected. I should have written to src-committers@. No, src-committers wouldn't have helped you. That's src developers only, not public. Do not cross-post src-committers with -current either. If you really want to have a public discussion, post to -current, and then a second hey, look over on -current to src-developers@. Or do a bcc: src-developers or something. But not a To:/CC: cross post. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: question on profiling code
On Mon, 17 Feb 2003, Bruce Evans wrote: On Sun, 16 Feb 2003, Julian Elischer wrote: In addupc_intr, if the increment cannot be done immediatly, the addres to increment the count for is stored and the increment is done later at ast or userret() time... Note that cannot be done immediatly is always except on sparc64's under FreeBSD, since incrementing the counter immediately is only implemented on sparc64's. Care to explain this statement? It doesn't corelate what I see in addupc_int() which is Machine Independent. is there any reason that the address of the PC needs to be stored? why is the address from the frame at that time not useable? is it because the PC in the return frame may be hacked up for signals? That's was good a reason as any. I think the next return to user mode is to the signal handler's context (if there is a signal to be handled). It would be wrong to use the signal handler's pc. Also, ast() doesn't have access to the frame, funny, it uses it.. and there is no macro like CLKF_PC() for general frames. They seem to be the same. Macro or no macro, ast and userret can certainly access the return address. This probably doesn't matter much, since signals are rare and the hitting on the signal handler's pc would be perfectly correct if the profiling interrupt occurred an instant later. that is true. Now there is a stronger reason: clock interrupt handling is fast, so it normally returns to user mode without going near ast(), and the counter is not updated until the next non-fast interrupt or syscall. This might not happen until another profiling interrupt clobbers the saved pc, not to mention the saved tick count (it could just increment the tick count so that ticks are assigned to the last saved pc instead of lost; currently, the tick count mostly just tracks KEF_OWEUPC so it need not be saved). This was broken by SMPng (hardclock() is not really a fast interrupt handler but is abused as one). However, normal applications probably make enough syscalls to get the right counter updated, provided we use the counter for the pc at fast interrupt time and not the counter for the pc later. I'm trying to fix this for multithreaded programs.. thanks for the answer.. I hadn't considered that reason. I assumed that the ASTPENDIG flag would be set, and that the AST would happen, (the userret certainly happens). (does it not?) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI timer bug
The clock on my ASUS P5A still runs at double speed unless I have debug.acpi.disable=timer in loader.conf (as it has for as long as we've had ACPI support). Do any ACPI wizards have any suggestions as to how I could track down the cause of this bug, and hopefully fix it? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
