All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Armin Schindler <armin@melware.de>
Cc: Adrian Bunk <bunk@stusta.de>,
	kai.germaschewski@gmx.de, isdn4linux@listserv.isdn4linux.de,
	linux-kernel@vger.kernel.org, kkeil@suse.de
Subject: Re: [2.6 patch] ISDN_CAPI_CAPIFS related cleanups
Date: Fri, 03 Feb 2006 09:53:48 +0100	[thread overview]
Message-ID: <1138956828.3731.2.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0602030941580.13271@phoenix.one.melware.de>

Hi Armin,

> > > > > This patch contains the following cleanups:
> > > > > - move the help text to the right option
> > > > > - replace some #ifdef's in capi.c with dummy functions in capifs.h
> > > > > - use CONFIG_ISDN_CAPI_CAPIFS_BOOL in one place in capi.c
> > > > 
> > > > I actually still like to see capifs removed completely. It is not really
> > > > needed if you gonna use udev. The only thing that it is doing, is to set
> > > > the correct permissions and make sure that the device nodes are created.
> > > > And with a 2.6 kernel this can be all done by udev.
> > > 
> > > udev is not mandatory.
> > > 
> > > Static /dev is still 100% supported and working fine.
> > 
> > and if you have static /dev then you can use mknod and chown by
> > yourself. If you use CAPI on any newer distribution with the latest 2.6
> > kernel you will have udev anyway and so no static /dev at all.
> 
> Sorry for my ignorance, but I think capifs was introduced to have own 
> dynamic 'files' like pts and not to have the restrictions of character 
> devices and the needed major/minor numbers.

I am under the impression that it was introduced to change the ownership
of the device node the current process. Nothing more, nothing less.
Please correct me if I am wrong here.
 
> So changing this to character device nodes may break applications
> out there.

Actually I stopped compiling in and using capifs over a year ago and I
never had any problems with it. However you must ensure that the device
has been created by udev, nut nowadays this is no problem.

Regards

Marcel



  reply	other threads:[~2006-02-03  8:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-31 21:33 [2.6 patch] ISDN_CAPI_CAPIFS related cleanups Adrian Bunk
2006-01-31 21:44 ` Marcel Holtmann
2006-02-02 21:40   ` Adrian Bunk
2006-02-02 23:57     ` Marcel Holtmann
2006-02-03  8:45       ` Armin Schindler
2006-02-03  8:53         ` Marcel Holtmann [this message]
2006-02-03 10:18           ` Armin Schindler
2006-02-03 19:57             ` Marcel Holtmann
2006-02-12 11:09               ` Carsten Paeth
2006-02-12 11:36                 ` Marcel Holtmann
2006-02-18 15:46                   ` Carsten Paeth
2006-02-01  8:43 ` Armin Schindler
2006-02-01 10:44   ` Adrian Bunk
2006-02-01 11:01     ` Armin Schindler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1138956828.3731.2.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=armin@melware.de \
    --cc=bunk@stusta.de \
    --cc=isdn4linux@listserv.isdn4linux.de \
    --cc=kai.germaschewski@gmx.de \
    --cc=kkeil@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.