Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Feb 2012 09:45:48 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Brooks Davis <brooks@FreeBSD.org>
Cc:        Aleksandr Rybalko <ray@ddteam.net>, freebsd-arch@FreeBSD.org
Subject:   Re: dynamic attach of hinted devices
Message-ID:  <4996D1CF-25E5-4422-996C-DF23B5C10732@bsdimp.com>
In-Reply-To: <20120210110243.GA2012@lor.one-eyed-alien.net>
References:  <20120131213857.86c81626.ray@ddteam.net> <20120210110243.GA2012@lor.one-eyed-alien.net>

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

On Feb 10, 2012, at 4:02 AM, Brooks Davis wrote:

> On Tue, Jan 31, 2012 at 09:38:57PM +0200, Aleksandr Rybalko wrote:
>> Hi FreeBSD hackers,
>>=20
>> at first I want to say this: :)
>> WARNING: FOLLOWING DEVCTL PATCH MAY EASILY PANIC YOUR SYSTEM, PLEASE
>> DO NOT TRY IT ON PRODUCTION SERVERS AND TRY IT WITH FILESYSTEMS =
MOUNTED
>> AS READONLY :)))))
>>=20
>> So I introduce two patches first one [1] used to migrate from
>> static_hints or hints in the static_kenv to dynamic hints.
>>=20
>> sysctl kern.hintmode=3D2 will copy hints from static hints or from =
static
>> kenv and put it into dynamic kenv. Those will allow to manipulate =
hints
>> values and attach hinted devices with devctl tool.
>>=20
>> Second [2] allow attach/detach devices with userland tool devctl.
>>=20
>> devctl tool allow add and initialize new devices which is not able to
>> be autoenumerating, such a hinted devices.
>>=20
>> Both designed to have ability update EEPROM items in runtime, since
>> some device can't work in mode when it accessible like a EEPROM chip.
>>=20
>> Example:
>> # sysctl kern.hintmode=3D2
>> # kenv hint.mx25l.0.at=3D"spibus0"
>> # kenv hint.mx25l.0.cs=3D0
>> # kenv hint.mx25l.0.chipname=3D"at25128"
>> # devctl hinted spibus 0 mx25l 0
>> mx25l0: <M25Pxx Flash Family> at cs 0 mode 0 on spibus0
>> mx25l0: at25128, sector 64 bytes, 256 sectors
>> GEOM: new disk flash/spi0
>>=20
>> Someone may found it also useful for testing device attach/detach =
code
>> (memory leaks, resource allocation, etc).
>>=20
>> So, say me please your opinion.
>=20
> I skimmed over the patch and the concept looks good to me.  I'm =
probably
> not the right person to review this proposal in detail, but perhaps =
John
> Baldwin (cc'd) could do it or suggest someone.

I've looked at it and it looks OK, but I had lots of feedback I didn't =
have time to write up.  I like the concept, but have lots of suggestions =
for improvement since I'd like to see this more generically done.

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4996D1CF-25E5-4422-996C-DF23B5C10732>