From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SU71D-0004dw-Pj for garchives@archives.gentoo.org; Tue, 15 May 2012 01:57:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 946B0E089E; Tue, 15 May 2012 01:57:24 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 7D7E2E0845 for ; Tue, 15 May 2012 01:56:37 +0000 (UTC) Received: by obbuo19 with SMTP id uo19so10300153obb.40 for ; Mon, 14 May 2012 18:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dee.su; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=2Rp4eIEOBF6IykczDg3XuN7rXR4dsK24EnjZGl8ghxA=; b=ZZVci0+aQ2TeSkMVv8lPtHW/12nrbAvRrwF0Rtt1YnAqcBSa+8cYf2pEvi78D6yiBj xz2RmzDH156Cab87yKlJKe0zed1EIDjSJxnNkqIGUcvWqH2k6/XqiNMgJlpNscWeeUGd q/txuVY1r8qaIX4KH0sQ6nOM2qwzyTVJxFZNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=2Rp4eIEOBF6IykczDg3XuN7rXR4dsK24EnjZGl8ghxA=; b=Lbdvg/v9bEuk9F90lhhRdpaOzDhrg70w2pCqkE0As2lxI0UHLVvLubyH93C2fYMz/q CfIVvmd7E16qGBffsN/1uJP364JD2C+6hNtjjUFdgRBlpGHS5GzAQSBTsKp/+gHFWWth l3baiIaLC5XyQfwkb4X7N/VjI0+1byuI5XjA2D4mUFHyFKxQyblwuy0E4VWeIQ8TNq8r G+Z9R7ab33SCoGTUoDEDVGJjdxV5l9LcH7oePuC+b6NQOzYY/d0zNVqeSFyBYVRgW0Qy WF4odfplKfl/e0sdHmvQAXIFBWeu04rijUdLs9dewUM05829HQTHJ925QvryT8Hp7RJS rZiw== Received: by 10.60.4.1 with SMTP id g1mr14697092oeg.55.1337046996715; Mon, 14 May 2012 18:56:36 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.182.160.102 with HTTP; Mon, 14 May 2012 18:56:15 -0700 (PDT) In-Reply-To: <20120515012336.GB18105@kroah.com> References: <20120514075353.GB5819@waltdnes.org> <20120515012336.GB18105@kroah.com> From: Maxim Kammerer Date: Tue, 15 May 2012 04:56:15 +0300 Message-ID: Subject: Re: [gentoo-dev] Stability of /sys api To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlzTNNJgvGCIUcuMbTbRzCtbvKex9hTB1hXErVQr6RLYFuCfMAqguZ6oQiGELR8szBCzdrY X-Archives-Salt: f7b615d4-8157-4cfe-bdef-d5c7c8e5e083 X-Archives-Hash: b5f2d5b8c162697bfa71b8b1c198dfd8 On Tue, May 15, 2012 at 4:23 AM, Greg KH wrote: > We learned that this is not a good idea at all, and should be left to use= rspace helper applications > that listen for dbus messages. Could you perhaps expand a bit on those reasons? E.g., I had good experience with the following short script for coupling udev events with autofs: https://github.com/mkdesu/liberte/blob/master/src/usr/local/sb= in/ps-mount. Gentoo wiki has a similar tutorial as well. Granted, it is a single-user setup, but I can imagine it being extended to work with ConsoleKit. One obvious problem is mounting encrypted volumes. I thought about moving to e.g., udisks-glue (as a more standard solution), but from what I hear there are too many bugs with udisks at the moment. > Actually with all the hype about mdev these days, why not just use a 3 > year old version of udev (or maybe 4), that is probably what mdev is at > as far as functionality goes. I don't know at what state udev was 3 or 4 years ago, but mdev can: 1. Populate /dev (now unnecessary due to devtmpfs). 2. Handle ownership, permissions and symlinks to /dev nodes once they appear, according to simple rules (can be probably done with inotify). 3. Act as /sbin/hotplug, typically doing something equivalent to this one-l= iner: [ "${ACTION}" =3D add -a -n "${MODALIAS}" ] && modprobe -qb "${MODALIA= S}" I don't think mdev can do anything else. Building any serious framework on top of mdev seems pointless to me, since it will probably end up as a small subset of udev core reimplemented with scripts. --=20 Maxim Kammerer Libert=E9 Linux (discussion / support: http://dee.su/liberte-contribute)