OK, it's time to admit that our small team can't match
the pace of Digium's full-time developers and merge all patches
to zaptel-bsd sources in time. port and svn quite
outdated. I tried to update them several times but was distracted by
other things. The last time I decided to give a try to my old idea.
Porting process is quite routine and bsd-only chunks of code were
written a couple of years ago and hasn't been changed much since then.
So it was obvious to automate this process with some kind of script.
This script and its output could be found in -ng branch in zaptel-bsd svn.

On the moment "beastify" ports zaptel, ztcfg, wctdm and wctdm24xxp. Original
sources were taken from zaptel-1.4.9.2. wctdm and wctdm24xxp detect
cards though I had no time to test calls yet. No VPM support, but
it's in TODO. Even if this idea will fail for hardware modules, "zaptel"
module should be handled with this script just fine and it will help
hw vendors who support FreeBSD (like Sangoma) to maintain bsd version of
their drivers.

Yesterday, I have switched my BSD 7.0 for a Debian 4.0 to install my
TDM410P card on my gateway.

Now I`ll rollback the installation to test this new commited changes and
post the result here.

Thanks for your help and time.

Oleksandr Tymoshenko escreveu:

Quote:

Hello, people.

OK, it's time to admit that our small team can't match
the pace of Digium's full-time developers and merge all patches
to zaptel-bsd sources in time. port and svn quite
outdated. I tried to update them several times but was distracted by
other things. The last time I decided to give a try to my old idea.
Porting process is quite routine and bsd-only chunks of code were
written a couple of years ago and hasn't been changed much since then.
So it was obvious to automate this process with some kind of script.
This script and its output could be found in -ng branch in zaptel-bsd svn.

On the moment "beastify" ports zaptel, ztcfg, wctdm and wctdm24xxp. Original
sources were taken from zaptel-1.4.9.2. wctdm and wctdm24xxp detect
cards though I had no time to test calls yet. No VPM support, but
it's in TODO. Even if this idea will fail for hardware modules, "zaptel"
module should be handled with this script just fine and it will help
hw vendors who support FreeBSD (like Sangoma) to maintain bsd version of
their drivers.

On the topic of the bsd Driver we need the script published that splits the
files into thier sub directories. also need to know where the current version
stands. I will do my best to get back to porting 1.6 into the ports tree but
I still need a little more time to settle in. where does 1.4 stand has it
been updated?

we need to get more people that use asterisk on bsd to step forward and either
put in some time to help or help fund this so we can keep zaptel and asterisk
ported. As it is time consuming. Any Contibutions would help. even if its
small amounts they all pile up to help.

I still see a ajor need for asterisk on BSD the main being stablity, security,
performance.

On Thursday 22 May 2008 18:38:19 Oleksandr Tymoshenko wrote:

Quote:

Hello, people.

OK, it's time to admit that our small team can't match
the pace of Digium's full-time developers and merge all patches
to zaptel-bsd sources in time. port and svn quite
outdated. I tried to update them several times but was distracted by
other things. The last time I decided to give a try to my old idea.
Porting process is quite routine and bsd-only chunks of code were
written a couple of years ago and hasn't been changed much since then.
So it was obvious to automate this process with some kind of script.
This script and its output could be found in -ng branch in zaptel-bsd svn.

On the moment "beastify" ports zaptel, ztcfg, wctdm and wctdm24xxp.
Original sources were taken from zaptel-1.4.9.2. wctdm and wctdm24xxp
detect cards though I had no time to test calls yet. No VPM support, but
it's in TODO. Even if this idea will fail for hardware modules, "zaptel"
module should be handled with this script just fine and it will help
hw vendors who support FreeBSD (like Sangoma) to maintain bsd version of
their drivers.

OK, it's time to admit that our small team can't match
the pace of Digium's full-time developers and merge all patches
to zaptel-bsd sources in time. port and svn quite
outdated. I tried to update them several times but was distracted by
other things. The last time I decided to give a try to my old idea.
Porting process is quite routine and bsd-only chunks of code were
written a couple of years ago and hasn't been changed much since then.
So it was obvious to automate this process with some kind of script.
This script and its output could be found in -ng branch in zaptel-
bsd svn.

That URL requires a password. Is there anonymous access to the
repository?

I spoke to Digium people (and specifically to Mark Spencer) at a
conference some time back and discussed the BSD community. They were
encouraging to the efforts. Would Digium accept your patches upstream
so they did not need to be maintained separately? Or do they not want
to take responsibility for testing each release on FreeBSD?

Or would Apple be interested in helping the maintenance if it
ultimately might lead to Asterisk support on Darwin?

Finally, this name change for zaptel that was announced: is it just a
name change, or is this a change in direction for the zaptel project?

> OK, it's time to admit that our small team can't match
> the pace of Digium's full-time developers and merge all patches
> to zaptel-bsd sources in time. port and svn quite
> outdated. I tried to update them several times but was distracted by
> other things. The last time I decided to give a try to my old idea.
> Porting process is quite routine and bsd-only chunks of code were
> written a couple of years ago and hasn't been changed much since then.
> So it was obvious to automate this process with some kind of script.
> This script and its output could be found in -ng branch in zaptel-
> bsd svn.
>
> https://svn.pbxpress.com:1443/repos/zaptel-bsd/branches/ng/

That URL requires a password. Is there anonymous access to the
repository?
Yeah, sorry, forgot to mention it:

login: svn
password: svn

Quote:

I spoke to Digium people (and specifically to Mark Spencer) at a
conference some time back and discussed the BSD community. They were
encouraging to the efforts. Would Digium accept your patches upstream
so they did not need to be maintained separately? Or do they not want
to take responsibility for testing each release on FreeBSD?

Or would Apple be interested in helping the maintenance if it
ultimately might lead to Asterisk support on Darwin?
I haven't approached neither Digium nor Apple yet. What I have now is

not a set of patches but perl code that maps Linux KPI to FreeBSD's one
(where available), some compatibility layer and some logic tweaks that
required by FreeBSD (like device cloning to get per-open instance softc
struct). I'm not sure how far Digium is willing to go with it. It would
be great if there were OS-dependent (locking, module wrapper, etc..)
and OS-independent (logic, generic infrastructure operation) layers
in order to reduce amount of code that should be maintained by OS community.
It's my pipe dream for last three years :)

Quote:

Finally, this name change for zaptel that was announced: is it just a
name change, or is this a change in direction for the zaptel project?
It's just svn branch. Project name is still zaptel-bsd.

Last time I talked to digium about Asterisk+zaptel on bsd they said it was
great we had ported it and it worked. But they would not support it. Asit is
not on a linux platform that they support.

They say they have neither the time or the resources. and that if infact
patches where sent in they woul dhave no way to test and review them.

On Saturday 24 May 2008 04:10:10 Oleksandr Tymoshenko wrote:

Quote:

Aristedes Maniatis wrote:
> On 23/05/2008, at 8:38 AM, Oleksandr Tymoshenko wrote:
>> OK, it's time to admit that our small team can't match
>> the pace of Digium's full-time developers and merge all patches
>> to zaptel-bsd sources in time. port and svn quite
>> outdated. I tried to update them several times but was distracted by
>> other things. The last time I decided to give a try to my old idea.
>> Porting process is quite routine and bsd-only chunks of code were
>> written a couple of years ago and hasn't been changed much since then.
>> So it was obvious to automate this process with some kind of script.
>> This script and its output could be found in -ng branch in zaptel-
>> bsd svn.
>>
>> https://svn.pbxpress.com:1443/repos/zaptel-bsd/branches/ng/
>
> That URL requires a password. Is there anonymous access to the
> repository?

Yeah, sorry, forgot to mention it:
login: svn
password: svn

> I spoke to Digium people (and specifically to Mark Spencer) at a
> conference some time back and discussed the BSD community. They were
> encouraging to the efforts. Would Digium accept your patches upstream
> so they did not need to be maintained separately? Or do they not want
> to take responsibility for testing each release on FreeBSD?
>
> Or would Apple be interested in helping the maintenance if it
> ultimately might lead to Asterisk support on Darwin?

I haven't approached neither Digium nor Apple yet. What I have now is
not a set of patches but perl code that maps Linux KPI to FreeBSD's one
(where available), some compatibility layer and some logic tweaks that
required by FreeBSD (like device cloning to get per-open instance softc
struct). I'm not sure how far Digium is willing to go with it. It would
be great if there were OS-dependent (locking, module wrapper, etc..)
and OS-independent (logic, generic infrastructure operation) layers
in order to reduce amount of code that should be maintained by OS
community. It's my pipe dream for last three years :)

> Finally, this name change for zaptel that was announced: is it just a
> name change, or is this a change in direction for the zaptel project?

[Digium hat on, but I don't feel like re-subscribing to this group
from my Digium account. Replies to jtodd@digium.com please.]

I've been in discussions privately on several occasions with Digium
people about zaptel/DAHDI support for BSD, and there has been
interest but some trepidation. I will say that it's good to see that
the zaptel (now DAHDI) drivers have been supported this well on *BSD
for this long - it is a good sign that there is hope for them to be
included in the mainline tree. Now that I am a Digium employee,
perhaps I can pull the strings a little harder. :-)

Digium is not a *BSD shop, and they don't have the experience or
platforms required to keep the drivers up to date on *BSD, and I'm
sure they don't want to "support" *BSD as part of their commercial
offering at this time. I have had discussions with Russel Bryant,
who seemed to think the addition of the drivers was a good idea
though, but he's not the one to keep the zaptel/DAHDI code up to
date. I've asked the people in the hardware division if they would
be interested in seeing that addition, and I'm sure they'll come back
to me with a number of questions that I'll address here.

If I can get two people to commit themselves to keeping the *BSD
derivatives up to date, and to fix things on BSD systems as DAHDI
(nee zaptel) evolves over time, that would be a pre-requisite for
getting this into the "mainline" portions of DAHDI. It would
probably need to support FreeBSD, OpenBSD, and Darwin at a minimum.
Is NetBSD significantly different these days? I haven't kept up.

I can guarantee nothing, only that I can get things started within
Digium to have a serious look at making this part of the package.
They may ultimately not choose to do it because of the complexity.
Or perhaps it would be added as an "add-on" but that would still
imply keeping it up to date. However, I am almost absolutely sure
in it's current state it would not pass initial examination.

Also at a minimum, perhaps a README file or some sort of instructions
would be a good idea to put in the distribution - I used to be able
to figure out how to get this working for OpenBSD, but it's no longer
obvious and I don't have the hours to wrestle with different random
trials to find my way in the dark. Without documentation, the few
brave Linux (and *BSD) folks who try to test this will quickly give
up and move on to other tasks.

So, it would be great if the zaptel-bsd community could provide:

1) Two volunteers for keeping the *BSD portions of the code up to date.
2) FAQ, README, or other documentation on the distribution archive
3) Support for FreeBSD, OpenBSD, and Darwin in the package

If that is the case, I'll further try to get this adopted as either
an add-on or basic portion of the zaptel/DAHDI distribution. Again,
I can't say it will happen, only that I will try.

Last time I talked to digium about Asterisk+zaptel on bsd they said it was
great we had ported it and it worked. But they would not support it. Asit is
not on a linux platform that they support.

They say they have neither the time or the resources. and that if infact
patches where sent in they woul dhave no way to test and review them.

On Saturday 24 May 2008 04:10:10 Oleksandr Tymoshenko wrote:
> Aristedes Maniatis wrote:
> > On 23/05/2008, at 8:38 AM, Oleksandr Tymoshenko wrote:
> >> OK, it's time to admit that our small team can't match
> >> the pace of Digium's full-time developers and merge all patches
> >> to zaptel-bsd sources in time. port and svn quite
> >> outdated. I tried to update them several times but was distracted by
> >> other things. The last time I decided to give a try to my old idea.
> >> Porting process is quite routine and bsd-only chunks of code were
> >> written a couple of years ago and hasn't been changed much since then.
> >> So it was obvious to automate this process with some kind of script.
> >> This script and its output could be found in -ng branch in zaptel-
> >> bsd svn.
> >>
> >> https://svn.pbxpress.com:1443/repos/zaptel-bsd/branches/ng/
> >
> > That URL requires a password. Is there anonymous access to the
> > repository?
>
> Yeah, sorry, forgot to mention it:
> login: svn
> password: svn
>
> > I spoke to Digium people (and specifically to Mark Spencer) at a
> > conference some time back and discussed the BSD community. They were
> > encouraging to the efforts. Would Digium accept your patches upstream
> > so they did not need to be maintained separately? Or do they not want
> > to take responsibility for testing each release on FreeBSD?
> >
> > Or would Apple be interested in helping the maintenance if it
> > ultimately might lead to Asterisk support on Darwin?
>
> I haven't approached neither Digium nor Apple yet. What I have now is
> not a set of patches but perl code that maps Linux KPI to FreeBSD's one
> (where available), some compatibility layer and some logic tweaks that
> required by FreeBSD (like device cloning to get per-open instance softc
> struct). I'm not sure how far Digium is willing to go with it. It would
> be great if there were OS-dependent (locking, module wrapper, etc..)
> and OS-independent (logic, generic infrastructure operation) layers
> in order to reduce amount of code that should be maintained by OS
> community. It's my pipe dream for last three years :)
>
> > Finally, this name change for zaptel that was announced: is it just a
> > name change, or is this a change in direction for the zaptel project?
>
> It's just svn branch. Project name is still zaptel-bsd.

Hello. I've done a bit of work on making zaptel work with NetBSD.
While I can't say I'm an expert in the workings of the zaptel drivers, I'm
happy to help make the new stuff work with NetBSD as it's made ready for
FreeBSD and OpenBSD. For the record, NetBSD is closest to OpenBSD in its
implementation details, so, in most cases, when you have a define for
OpenBSD, it's also valid for NetBSD.
-Brian

On Jun 5, 3:04pm, John Todd wrote:
} Subject: Re: [Asterisk-bsd] Update on zaptel-bsd
} [Digium hat on, but I don't feel like re-subscribing to this group
} from my Digium account. Replies to jtodd@digium.com please.]
}
} I've been in discussions privately on several occasions with Digium
} people about zaptel/DAHDI support for BSD, and there has been
} interest but some trepidation. I will say that it's good to see that
} the zaptel (now DAHDI) drivers have been supported this well on *BSD
} for this long - it is a good sign that there is hope for them to be
} included in the mainline tree. Now that I am a Digium employee,
} perhaps I can pull the strings a little harder. :-)
}
} Digium is not a *BSD shop, and they don't have the experience or
} platforms required to keep the drivers up to date on *BSD, and I'm
} sure they don't want to "support" *BSD as part of their commercial
} offering at this time. I have had discussions with Russel Bryant,
} who seemed to think the addition of the drivers was a good idea
} though, but he's not the one to keep the zaptel/DAHDI code up to
} date. I've asked the people in the hardware division if they would
} be interested in seeing that addition, and I'm sure they'll come back
} to me with a number of questions that I'll address here.
}
} If I can get two people to commit themselves to keeping the *BSD
} derivatives up to date, and to fix things on BSD systems as DAHDI
} (nee zaptel) evolves over time, that would be a pre-requisite for
} getting this into the "mainline" portions of DAHDI. It would
} probably need to support FreeBSD, OpenBSD, and Darwin at a minimum.
} Is NetBSD significantly different these days? I haven't kept up.
}
} I can guarantee nothing, only that I can get things started within
} Digium to have a serious look at making this part of the package.
} They may ultimately not choose to do it because of the complexity.
} Or perhaps it would be added as an "add-on" but that would still
} imply keeping it up to date. However, I am almost absolutely sure
} in it's current state it would not pass initial examination.
}
} Also at a minimum, perhaps a README file or some sort of instructions
} would be a good idea to put in the distribution - I used to be able
} to figure out how to get this working for OpenBSD, but it's no longer
} obvious and I don't have the hours to wrestle with different random
} trials to find my way in the dark. Without documentation, the few
} brave Linux (and *BSD) folks who try to test this will quickly give
} up and move on to other tasks.
}
} So, it would be great if the zaptel-bsd community could provide:
}
} 1) Two volunteers for keeping the *BSD portions of the code up to date.
} 2) FAQ, README, or other documentation on the distribution archive
} 3) Support for FreeBSD, OpenBSD, and Darwin in the package
}
} If that is the case, I'll further try to get this adopted as either
} an add-on or basic portion of the zaptel/DAHDI distribution. Again,
} I can't say it will happen, only that I will try.
}
} JT
}
} --
} John Todd jtodd@digium.com
} Asterisk Open Source Community Director
}
}
}
} At 8:34 AM -0400 2008/5/26, Richard Neese wrote:
} >
} >Last time I talked to digium about Asterisk+zaptel on bsd they said it was
} >great we had ported it and it worked. But they would not support it. Asit is
} >not on a linux platform that they support.
} >
} >They say they have neither the time or the resources. and that if infact
} >patches where sent in they woul dhave no way to test and review them.
} >
} >On Saturday 24 May 2008 04:10:10 Oleksandr Tymoshenko wrote:
} >> Aristedes Maniatis wrote:
} >> > On 23/05/2008, at 8:38 AM, Oleksandr Tymoshenko wrote:
} >> >> OK, it's time to admit that our small team can't match
} >> >> the pace of Digium's full-time developers and merge all patches
} >> >> to zaptel-bsd sources in time. port and svn quite
} >> >> outdated. I tried to update them several times but was distracted by
} >> >> other things. The last time I decided to give a try to my old idea.
} >> >> Porting process is quite routine and bsd-only chunks of code were
} >> >> written a couple of years ago and hasn't been changed much since then.
} > > >> So it was obvious to automate this process with some kind of script.
} >> >> This script and its output could be found in -ng branch in zaptel-
} >> >> bsd svn.
} >> >>
} >> >> https://svn.pbxpress.com:1443/repos/zaptel-bsd/branches/ng/
} >> >
} >> > That URL requires a password. Is there anonymous access to the
} >> > repository?
} >>
} >> Yeah, sorry, forgot to mention it:
} >> login: svn
} >> password: svn
} >>
} >> > I spoke to Digium people (and specifically to Mark Spencer) at a
} >> > conference some time back and discussed the BSD community. They were
} >> > encouraging to the efforts. Would Digium accept your patches upstream
} >> > so they did not need to be maintained separately? Or do they not want
} >> > to take responsibility for testing each release on FreeBSD?
} >> >
} >> > Or would Apple be interested in helping the maintenance if it
} >> > ultimately might lead to Asterisk support on Darwin?
} >>
} >> I haven't approached neither Digium nor Apple yet. What I have now is
} >> not a set of patches but perl code that maps Linux KPI to FreeBSD's one
} >> (where available), some compatibility layer and some logic tweaks that
} >> required by FreeBSD (like device cloning to get per-open instance softc
} >> struct). I'm not sure how far Digium is willing to go with it. It would
} >> be great if there were OS-dependent (locking, module wrapper, etc..)
} >> and OS-independent (logic, generic infrastructure operation) layers
} >> in order to reduce amount of code that should be maintained by OS
} >> community. It's my pipe dream for last three years :)
} >>
} >> > Finally, this name change for zaptel that was announced: is it just a
} >> > name change, or is this a change in direction for the zaptel project?
} >>
} >> It's just svn branch. Project name is still zaptel-bsd.
} >
} >
} >
} >_______________________________________________
} >--Bandwidth and Colocation Provided by http://www.api-digital.com--
} >
} >Asterisk-BSD mailing list
} >To UNSUBSCRIBE or update options visit:
} > http://lists.digium.com/mailman/listinfo/asterisk-bsd
}
}
} _______________________________________________
} --Bandwidth and Colocation Provided by http://www.api-digital.com--
}
} Asterisk-BSD mailing list
} To UNSUBSCRIBE or update options visit:
} http://lists.digium.com/mailman/listinfo/asterisk-bsd

[Digium hat on, but I don't feel like re-subscribing to this group
from my Digium account. Replies to jtodd@digium.com please.]

So, it would be great if the zaptel-bsd community could provide:

1) Two volunteers for keeping the *BSD portions of the code up to date.
2) FAQ, README, or other documentation on the distribution archive
3) Support for FreeBSD, OpenBSD, and Darwin in the package

If that is the case, I'll further try to get this adopted as either
an add-on or basic portion of the zaptel/DAHDI distribution. Again,
I can't say it will happen, only that I will try.

Thank you for reply, John. Unfortunately you're right and in current

state zaptel-bsd has no
chance to make it to mainline. Moreover there is no point in it. Because
it would duplicate all
functionality of linux version. In ideal world zaptel/DAHDI would have
thin OS-dependent
"compatiblity layer" and major part of logic being OS-indepent. So it's
this "compatibility
layer" that should be in mainline. Even if it would contain only Linux
parts it would make
porting and maintaining of zaptel/DAHDI infrastructure much easier for
other OSes.
Porting process is relatively easy, what is *really* hard is
maintenance. It's either one
ports every release from the scratch or tries to merge every svn commit
to your modified
sources. Both ways are PITA unless you don't have a bunch of scripts
making your life tolerable.

Although in modern *NIX derivatives a lot of KPI differs virtually
by types/function names,
arguments number and/or their order one can't separate this OS-dependent
layer from the rest
of code without having both versions before one's eyes or without
digging into other OS'es KPI.
That's where we come to item #1 and item #2 of your summary. Current
distribution even with
README would do no good. Much better would be a module ported to FreeBSD
with a list
of thing that have been changed. It would allow Digium to make some
estimates of efforts for
creating OS-independent layer and therefor to decide if they're
interested in it. I can do it for
non-hw "zaptel" module and for one of the hw drivers. And yes, I
volunteer to maintain *BSD part
of code if things would be done right (tm) :)

> https://svn.pbxpress.com:1443/repos/zaptel-bsd/branches/ng/
>
wctdm24xxp and wcte12xp drivers are ready for testing. I
tested first one with TDM410P and it seems to work. TE120P is in
queue for testing. No VPM support yet
wcte12xp detects TE121 (not TE120P as I wrote) and seems to work. There

is no
PRI on site to test card in action. So if you have card, PRI connection
and some time for
tests, please test and let me know.