lkml.org 
[lkml]   [2010]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 31/31] CAPI: Officially claim char major 191
From
Date
Hi Karsten,

> > > > I found no trace of this mysterious "pcl181" device, neither in-tree
> > > > nor out there in the wild. At the same time, the in-tree CAPI
> > > > middleware is using major 191 for many years now and obviously without
> > > > any conflict. Let's officially claim this major number.
> > >
> > > This is not the way it should have been done but whoever needs spanking
> > > got away with it years ago. Given that this seems the best way forward.
> > >
> > > With LANANA hat on
> >
> > actually in the days of udev, the capifs is not really needed anymore.
> > The right choice would be to remove it. I haven't been enabling it since
> > years.
> >
> So far I understand, the pppd capiplugin is the only user of it, so it could
> be disabled for most users without any problems, as long they are not using
> PPP connections via CAPI.

PPP connection via CAPI works just fine without capifs. You just need
udev to create the device nodes.

> I never understand capifs very well, I think that it can be dropped because of
> udev, but maybe need some adjustment in user space as well (make sure that
> udev did create the node before open it).

I am pretty sure that I send a patch for that a long long time ago. I
haven been using CAPI + PPP without capifs.

> I f I remember correctly, here was some proposal to replace the /dev/capi/
> nodes with devpts, this would remove the complete capi_tty device major
> as well.

Don't remember anything like this. However extending the kernel code
with a CAPI PPP channel type would be better actually.

Regards

Marcel




\
 
 \ /
  Last update: 2010-01-23 15:29    [W:0.064 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site