[Asterisk-Dev] exposing/maintaining more Zaptel info in /proc/zaptel ?

[Michael Loftis]

--On Tuesday, October 19, 2004 19:04 -0700 "Kevin P. Fleming" 
<kpfleming at starnetworks.us> wrote:

> Michael Loftis wrote:
>
>> /proc/zaptel/WCT1/info say would contain general information applicable
>> to all WCT1 Spans... (say the alarm state of each span...num
>> config/avail/used channels....)
>
> The Linux kernel is moving away from using /proc for anything that's not
> related to actual processes... like this.
>
> Any future information exposed (and controlled) by the zaptel drivers
> should be exposed via sysfs. Yes, that makes it 2.6+ specific, but it's
> the proper thing to do.

Realistically for me, and for a number of people that's quite some time 
away.  In my case that's likely a year or more away.  Theres no complete 
AFS support yet for one in my env, a couple of common configurations here 
still occasionally end up with corrupt disk/filesystem.  2.6.8 fixed most 
of that thankfully.  There's also still a bunch of old problems that the 
Linux developers refuse to acknowledge which means I have to move patches 
forward or find the 'new' way to fix it.  The new reiserfs isn't fully 
complete and bulletproof yet either.

It is getting there, but at a minimum all the parts wont be there it seems 
for another 6 months.  Then I'm not keen on jumping on it for production 
for about 3-6 months after that.  Yeah, old school I know, but when you're 
working at 90% you do not have time to rebuild a system because the kernel 
scribbled int eh wrong spot and killed the filesystem, or deal with irate 
customers because their box is now as stable as a teenage girlfriend and 
they for the most part don't see any differences or advantages to the 
'upgrade.'

I'd be more than happy to code it with 'alternate' codepaths that use 
sysfs, that means for me reading up on and figuring out sysfs, but if I do 
it I can't test it as well.  I've got one system I use at the moment for 
2.6 play but my production gear is/will be 2.4 for the near future.  Though 
maybe in one or two of the pure IP environments I could convert them to 2.6 
today.

Anyway I appreciate the note, but it shouldn't be too big of a deal to make 
sure there's a conditional around what gets compiled and support both by 
using wrapper functions.