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.
>
> I really don't know. Calle should be asked, I think he did that.
I asked him some time ago, but never got a final feedback for it.
> > > 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.
>
> I use capi-ppp connections with capifs. If you don't use capifs, how do you
> do ppp over CAPI?
>
> What about the major number? Wouldn't we need a major number then?
It has already a major number.
> If udev is creating the device, it may be not existent when the application
> expects it. E.g. the application is doing the ioctl to retreive the
> connection number (filename) and expects to be able to open it. But in case
> of udev, it might be not done in that time. So the application needs to wait
> for some time..., but how long? I don't like this idea.
This is a small race condition that existed with the original udev, but
it was easy to work around it. Adding a simple sleep is enough and I did
the same with Bluetooth RFCOMM. However it should be work nowadays, but
I am not 100% sure. We should check this with the udev guys.
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
