HEADSUP: Change of makedev() semantics.
Greg 'groggy' Lehey
grog at FreeBSD.org
Sun Sep 28 16:59:12 PDT 2003
On Sunday, 28 September 2003 at 19:46:20 -0400, Robert Watson wrote:
>
> On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote:
>
>> On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote:
>>> Basically:
>>>
>>> 3. If you do a "normal" device driver, cache the result
>>> from when you call make_dev().
>>> ...
>>>
>>> ./dev/vinum
>>> Failure to cache result of make_dev() ?
>>
>> Where should this be cached? Can you point to example code?
>
> Actually, it looks like Vinum is caching the dev_t's,
Ah, you mean saving the results rather than calling make_dev() every
time? Yes, it only calls make_dev() once for any device.
> but it's not always using them to get back to the dev_t--sometimes
> it's invoking makedev() instead. However, this appears to happen
> only in the vinumrevive.c code, so I'm not sure if that's a property
> of the cached reference being unavailable it looks like it should be
> available in that context though.
No, it should always be available. I was going to say "I don't see
any references to make_dev() in vinumrevive.c, nor any references to
makedev() at all", but I see that VINUM_SD includes both.
> I.e., using sd->dev instead of VINUM_SD() -- it looks like there is
> a valid (struct sd *) reference there to follow, so you can get to
> the dev_t without doing a makedev().
Yes, this is a bug (and an indication of the dangers of using macros :-)
I'll fix it.
Greg
--
See complete headers for address and phone numbers.
NOTE: Due to the currently active Microsoft-based worms, I am limiting
all incoming mail to 131,072 bytes. This is enough for normal mail,
but not for large attachments. Please send these as URLs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20030929/dc184e93/attachment.bin
More information about the freebsd-current
mailing list