Re: [Libcdio-devel] [PATCH] Remove unnecessary high-memory safe wrapper for DosDevIOCtl() on OS/2

[Rocky Bernstein]

To be clear when I write:

I feel like you and/or Portia should be the maintainers of OS2 libcdio.


I mean you should set up a separate repository that you maintain.

On Tue, Nov 29, 2016 at 8:02 AM, Rocky Bernstein <address@hidden> wrote:

> > Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper.
>
> I see that SafeDosDevIOCtl went in libcdio August 2014 and was in the 0.93
> release in September.  kLIBC 0.6.6 was released the next month in October
> 2014. How is it that they happened to use exactly that same very specific
> name?  Given this has been this way for two years already, it doesn't feel
> like this is a pressing issue that has been bothering a lot of people. And
> why didn't you mention this earlier?
>
>
> Let's go back to our correspondence two years ago:
>
> You:
>
> Hi/2.
>> Rocky Bernstein wrote:
>> > Ok, then you can be responsible for OS/2 . That means that you will be
>> > *expected to test, in advance, releases*. [emphasis added] Note that
>> this is a change from the
>> > laxness we've had in the past with respect to releases.
>> >
>> No problem.
>> > If you disappear and there is no one else to take responsibility, the
>> > ability to test OS/2 disappears, then OS/2 support in libcdio may
>> disappear
>> > as well.
>> >
>> Ooops... I feel the very much responsibility. ^^
>>
>>
> Ok. There was a release this year and that would have been an ideal time
> to get this change in. You blew it.
>
>
>
> So what I wrote in over two years ago is still true:
>
> About a month and a half ago we were discussing dropping libcdio's OS/2
>> driver altogether.  See http://lists.gnu.org/archi
>> ve/html/libcdio-devel/2014-06/msg00004.html
>> What motivated this was the desire to change the API to add
>> get_track_isrc and Robert Kausch mentioned he had no way to test OS/2. In
>> that, we realized that basically no one *is* actively testing OS/2.
>
>
> And that is still feels like the situation now.  There have been API
> changes and there are ones that may come up.
>
> In the past, I suggested setting up libcdio developer access to OS/2. That
> hasn't happened.
>
> So given the history, your lack of involvement and commitment, the
> smallness of the OS/2 libcdio community, the lack of libcdio developer
> access, and the general lack of libcdio resources,  I feel like you and/or
> Portia should be the maintainers of OS2 libcdio. I'll be happy to
> contribute to that.
>
> That said, I welcome comments from you and other people on the libcdio
> developers mailing list.
>
>
> On Tue, Nov 29, 2016 at 6:55 AM, KO Myung-Hun <address@hidden> wrote:
>
>> Hi/2.
>>
>> Rocky Bernstein wrote:
>> > At the risk of going down a rabbit hole of OS2 stuff which I doubt many
>> > people use, (you are the only one I am aware of that has *ever* used
>> > libcdio), I wonder about this. Is there harm in having the wrapper
>> there?
>> >
>> > The last OS2 release was in 2000 with and end release date of 2006, a
>> > decade ago.
>> >
>> > Removing the code above would force people to use
>> > <https://trac.netlabs.org/libc>kLIBC v0.6.6 <
>> https://trac.netlabs.org/libc>,
>> > which I guess is an add-on.
>> >
>> > I'd be grateful if you'd explain the harm of keeping the old code.
>> >
>>
>> Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper. So call to
>> the wrapper leads into 'not enough memory' due to a recursive call.
>>
>> kLIBC v0.6.6 has backward compatibility. As well as kLIBC v0.6.6
>> provides older versions of DLLs forwarding to v0.6.6. So even if people
>> upgrade their kLIBC to v0.6.6, they will not encounter any problem at
>> all. And most of all OS/2 users are already using kLIBC v0.6.6.
>>
>> Not enough ?
>>
>> --
>> KO Myung-Hun
>>
>> Using Mozilla SeaMonkey 2.7.2
>> Under OS/2 Warp 4 for Korean with FixPak #15
>> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>>
>> Korean OS/2 User Community : http://www.ecomstation.co.kr
>>
>>
>>
>