Re: [2.6 patch] ISDN_CAPI_CAPIFS related cleanups

[Marcel Holtmann <marcel@holtmann.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/