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

[KO Myung-Hun]

Rocky Bernstein 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?
> 

The story is like this. 'Safe' prefix had been already used by kLIBC for
APIs suffering from the same problem as DosDevIOCtl(). It was my mistake
to take the same prefix for DosDevIOCtl() as kLIBC. After all, this led
to the same name.

However, this approach had no problem until kLIBC v0.6.5. Because
DosDevIOCtl() was not a macro to SafeDosDevIOCtl. So at that time,
libcdio has no problem with DosDevIOCtl(). Even if kLIBC v0.6.6 having
SafeDosDevIOCtl() was released, libcdio 0.93 release pre-built with
kLIBC v0.6.5 has not been affected. Because it calls DosDevIOCtl()
correctly not a SafeDosDevIOCtl().

The reason why I didn't notice this, is that I did build tests only
before 0.94 release. Build problems did not occur. In addition, I didn't
expect kLIBC 0.6.6 release causes this problem. However, with 0.94
release, I built and ran test programs of libcdio 0.94, then I noticed
the problem.

> 
> 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.
> 

Admit. My mistake. I should have done tests for actual working states of
libcdio as well as build tests.

> 
> 
> 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/archive/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.
> 

Since 0.93 release, are there any significant changes I missed ? I
think, there are no such changes. I didn't have to do any activity for OS/2.

> That said, I welcome comments from you and other people on the libcdio
> developers mailing list.
> 

Do you mean fork ? Or other branch ? Anyway, I don't think it would be a
good idea.

-- 
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