Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Aug 1999 01:00:37 -0700 (PDT)
From:      Julian Elischer <julian@whistle.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Bruce Evans <bde@zeta.org.au>, jb@cimlogic.com.au, atrens@nortelnetworks.com, current@FreeBSD.ORG, luigi@labinfo.iet.unipi.it
Subject:   Re: problem with vnconfig -s labels ... 
Message-ID:  <Pine.BSF.3.95.990822005951.5602B-100000@current1.whistle.com>
In-Reply-To: <11263.935217470@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 21 Aug 1999, Poul-Henning Kamp wrote:

> In message <199908210630.QAA05678@godzilla.zeta.org.au>, Bruce Evans writes:
> >>Hmmm, I know this is your code, but are you sure? 8-). My understanding of
> >>dkmodslice() and friends is that they manipulate dev_t entries, but don't
> >>actually initialise them. Since the subr_diskslice code takes a dev_t
> >
> >dkmodslice() once just manipulated bits in dev_t scalars.  Now that dev_t
> >is a pointer, dkmodslice() has to create something for the pointer to
> >point to.  That something needs to be fully initialised and not created
> >more than once.  The initialisation is apparently incomplete.  Multiple
> >creation is avoided by searching the list of previously created entries.
> >
> >Now I understand why my memory is filling up with unused dev_t
> >entries :-).  subr_diskslice churns through a not insignificant part
> >of the per-drive minor number space (32 slices * 8 partitions * {raw,
> >buffered}), using dkmodslice to create new dev_t's.
> 
> yes, this is the remaining sticky issue, and the only cure I know for
> this and for the DEVFS issue is to relayer the slice/label processing
> out of the device driver entirely.  This is now almost possible to do.


Ehem... it was all working before it was ripped out...
that's EXACTLY what SLICE was.


> 
> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990822005951.5602B-100000>