bruce@stride.UUCP (Bruce Robertson) (02/21/86)
I was wondering about something I saw in "subr_prf.c" in the 4.2 BSD kernel sources. The comments for the function uprintf() advertise that you can call it from an interrupt routine to send a message to the current user's terminal. However, the code that finds out the user's current terminal references u.u_ttyp. This means that uprintf() will print its message on the terminal of the *currently running* process. Which process this is is essentially random, and almost always NOT the process that caused the interrupt to occur. I can't think of any situation where you would want to actually call uprintf() from an interrupt routine. Any comments? -- Bruce Robertson UUCP: cbosgd!utah-cs!utah-gr!stride!bruce ARPA: stride!bruce@utah-gr.arpa
chris@umcp-cs.UUCP (Chris Torek) (02/22/86)
In article <559@stride.stride.UUCP> bruce@stride.UUCP (Bruce Robertson) writes: > The comments for the function uprintf() advertise that you can > call it from an interrupt routine to send a message to the > current user's terminal. [But] uprintf() will print its message > on the terminal of the *currently running* process. Right you are. > I can't think of any situation where you would want to actually > call uprintf() from an interrupt routine. Messages like `no write ring', while they do not really belong in the kernel, are useful; these can be done by noting the lack of a write ring in some per-device data structure, and having the device open routine do the uprintf() as well as returning an error. (Some tape drives do not have write lock as a status bit: you must ask.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu