Date: Fri, 12 Nov 1999 14:24:30 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: ken@kdm.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, chris@calldei.com, sjr@home.net, freebsd-bugs@FreeBSD.ORG Subject: Re: make_dev() warnings Message-ID: <199911120524.OAA11399@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: Your message of "Thu, 11 Nov 1999 21:14:04 -0700 (MST)" References: <199911120414.VAA31806@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Nov 1999 21:14:04 -0700 (MST), "Kenneth D. Merry" <ken@kdm.org> said: ken> [ Your character set is kinda screwed up. A lot of the stuff below came ken> out as 8-bit characters... ] Sorry for that. Maybe some 8bit chars jumped into the last mail of mine when I cut & pasted a part of a source, but I hove no idea why. It used to work properly... >> It would help to add a new argument to periph_init_t, so that a unit >> number(or a periph?) can be passed from sys/cam/cam_xpt.c:xpt_finishconfig() >> to sys/cam/cam_xpt.c:xpt_periph_init() and the other functions. None >> of the CAM drivers seem to call make_dev(). ken> If I can decipher what you're saying there, I think you're talking about ken> probably having cam_periph_alloc() or something similar allocate the dev_t ken> node at attach time. Yes, that is my main idea. ken> - the sa and target drivers have multiple minor device nodes, and the ken> sa(4) driver in particular has a large number of minor entries, and a ken> weird minor numbering scheme pcm(4) has several minor numbers as well. It simply calls make_dev() for each of mixer, audio, dsp and dspW. Could the number of the minor entries for sa(4) depend on a drive? Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@freebsd.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911120524.OAA11399>