Re: major number leak with modules?

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sun, 07 Dec 2003 20:45:43 +0100
In message <20031207193748.GB98718_at_cnd.mcgill.ca>, Mathew Kanner writes:
>On Dec 07, Poul-Henning Kamp wrote:
>> In message <20031207173959.GE42518_at_cicely12.cicely.de>, Bernd Walter writes:
>> >The situation was the following during driver development.
>> >It's an USB driver and kldload'ed.
>> >A plugged in device got major 247 for the nodes it created.
>> >On unplugging the nodes were destroyed.
>> >kldunloading the driver and kldloading the next revision created
>> >nodes with major 246 for new devices.
>> >
>> >Do we have a leak with major numbers or is the old major number free
>> >after last destroy_dev and assigning algorithm just took the next.
>> 
>> Yes, repeatedly loading/unloading will leak majors.
>> 
>> I have some ref-counting code to solve this problem.  Warners
>> axe-swinging in the old ISA drivers made it easier, but some necessary
>> but uncommitted patches to the sound code from cg_at_ are still at
>> road-block.
>
>	Hello Poul-Henning,
>	It's my understanding that Cameron has submitted patches to
>you.  If you have no objection to them, please commit them.
>Otherwise, I will try to work some patches that are favorable to you.

Yes, I have his patches here but have done no testing apart from
compilining them, It was my impression that Cameron wanted to commit
himself ?

I've put the patch here, in case you havn't seen it:
	http://phk.freebsd.dk/patch/sound.patch


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sun Dec 07 2003 - 10:46:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:32 UTC