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

[Rocky Bernstein]

>
> The story is like this.  'Safe' prefix had been already used by kLIBC ...


Thanks for the information.  I appreciate it.

Since 0.93 release, are there any significant changes I missed ? I
> think, there are no such changes.


The changes are listed in NEWS. Some of them could have like the eject
fixes or some of the bugs could effect OS/2. And new functions have been
added which aren't used on OS/2 which is not a desirable state for someone
who uses or programs against libcdio across multiple platforms.

 I didn't have to do any activity for OS/2.


This is *exactly *the wrong-minded thinking that  brings us to the current
 problem. You didn't do activity on OS/2 libcdio, but others (and possibly
you) did make changes on kLIBC. And when things change in the (preferred)
OS environment or in libcdio, someone has to check that things haven't
broken. That's why we have the libcdio tests.

Someone has to be running those periodically. None of the libcdio
developers have a way to easily test this on OS2, so we haven't.  I thought
it was the understanding that you were going to take on this responsibility.

And that's the *only *reason OS/2 support hasn't been dropped altogether
before, which in my opinion is the responsible thing to do. IBM has said
"end of life support" was 2006. Well in 2016 I think we need to say from
the libcdio side, that's also officially the case.

Do you mean fork ? Or other branch ?


I mean fork. In other words, copy the git repository or work from release
tarballs or however you prefer to handle it.

Anyway, I don't think it would be a good idea.


Why not?


On Thu, Dec 1, 2016 at 3:06 AM, KO Myung-Hun <address@hidden> wrote:

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