From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 12:33:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADB11106566C; Mon, 25 Apr 2011 12:33:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D2E6A8FC18; Mon, 25 Apr 2011 12:33:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so2456027bwz.13 for ; Mon, 25 Apr 2011 05:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=2PsN9cps+lfOSwgrtebU11MlHip0iqRFvtC32o2hv+I=; b=DDYGh6H9fNsg4pRz6IJHLWQ2+3XyYUkgHLABxHpyPn9/640p6CrzefpAr1IfSZc2fU wp0LW6uv6kkm7lDb2TcVM+1NvyWS/GGyiMYHtRUhNDfPwGVERGwNSZNa9dU8yD8g2NCo 4BvLp2Ahi2JNh3WyaCvoKGox62sloqHOXDM9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=OZIzdbfWXEg+mA6SGslkpKv6DjEVUw/HDWLdvpGGvY3IP5JtIEGupEf6WO2ywE4ue+ mMp8TR7GNXJcZoXGvvJYaI0LBjCyyVvbLPE3MSblKBhSKjPCdOV/VRMORElVuLZlHNQZ DVsyHAzoFrfF/VL9siQ25Kp5d7KTG38+pNTAA= Received: by 10.204.85.8 with SMTP id m8mr3330208bkl.139.1303734806577; Mon, 25 Apr 2011 05:33:26 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q18sm3248504bka.3.2011.04.25.05.33.24 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 05:33:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB56A11.9030407@FreeBSD.org> Date: Mon, 25 Apr 2011 15:33:21 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marius Strobl References: <4DB54BA9.5050901@FreeBSD.org> <20110425121624.GA19134@alchemy.franken.de> In-Reply-To: <20110425121624.GA19134@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD-Current , Robert Watson Subject: Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:33:28 -0000 Marius Strobl wrote: > On Mon, Apr 25, 2011 at 01:23:37PM +0300, Alexander Motin wrote: >> I've implemented following patch to keep basic compatibility for the >> migrating users. I don't like such hacky things, but at least I tried to >> make it less invasive. >> >> The idea: >> - New xpt_path_legacy_ata_id() function in CAM tries to predict bus >> unit number and then device unit number for specified path, as if it was >> with legacy ATA with ATA_STATIC_ID option. >> - on attach, ada driver fetches that number (if not disabled using >> tunable kern.cam.ada.legacy_aliases), prints to console something like: >> ada0: Previously was known as ad12 >> , and sets kernel environment variable like: >> kern.devalias.ada0="ad12" >> - when geom_dev tastes new geom and creates device node for it, it also >> tries to match prefix of the device name with present kern.devalias.* >> enviromnent variables, and, if some match found, creates alias with >> substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.). >> >> The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch >> >> I did few tests and it seems like working -- two sets of device nodes >> appeared for each device, I can successfully label and mount any of them. >> >> What will not work: >> - old device names won't be seen inside GEOM, so users who hardcoded >> provider names in gmirror/gstripe/... metadata (not the default >> behavior) are still in trouble. >> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel >> without it, he should update device names manually. >> - it won't work for users with hot-unplugging ATA controllers (not >> devices), but I believe it is really rare case. >> - low-level tools, such as smartmontools, won't be able to work with >> alias devices, as background ada driver doesn't implements legacy >> ioctls. May be I could partially fix this. >> >> Except those, I think this patch should work for the most of users. >> >> Any more objections/ideas? Is this an acceptable solution? > > given that only the amd64, i386 and pc98 GENERIC kernel configuration > files had ATA_STATIC_ID enabled by default it would be highly desireable > that your compatibility shim also only mimics that behavior on these > archs or probably better actually check for ATA_STATIC_ID and put that > option back into the respective kernel configuration files. You are right. I have also thought about restoring that option, but haven't related it with architectures. -- Alexander Motin