From dyeo at gmx.com  Mon Aug  3 18:39:33 2026
From: dyeo at gmx.com (Dave Yeo)
Date: Mon, 3 Aug 2026 09:39:33 -0700
Subject: [smartmontools-support] State of OS/2 port
Message-ID: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>

Hi, compiling the latest smartmontools git on ArcaOS (OEM version of 
OS/2, arcanoae.com) configure output this at the tail,
```
configure: WARNING:
This version of smartmontools does not use C++14, C++17 or C++20 
enhancements,
but future versions possibly will.
This script was unable to determine a compiler option to enable C++20.
Please send info about compiler and platform to
smartmontools-support at listi.jpberlin.de - Thanks!

configure: WARNING:
The OS/2 port of smartmontools is unmaintained.  Please report the test
results to smartmontools-support at listi.jpberlin.de - Thanks!
```
Smartmontools compiled fine and seems to work fine. I've attached the 
results of make check from the system's GCC, 9.2.0 and the latest 
available, 15.2.0. Not sure of other tests that I can do.
Not subscribed so please CC me on any replies.
Thanks
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_1520.log
Type: text/x-log
Size: 1614 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/smartmontools-support/attachments/20260803/e82318ec/attachment.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_920.log
Type: text/x-log
Size: 1652 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/smartmontools-support/attachments/20260803/e82318ec/attachment-0001.log>

From Christian.Franke at t-online.de  Tue Aug  4 17:33:03 2026
From: Christian.Franke at t-online.de (Christian Franke)
Date: Tue, 4 Aug 2026 17:33:03 +0200
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
Message-ID: <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>

Hi Dave,

thanks for the positive feedback.

Dave Yeo via Smartmontools-support wrote:
> Hi, compiling the latest smartmontools git on ArcaOS (OEM version of 
> OS/2, arcanoae.com) configure output this at the tail,

Is there any free (evaluation?) version of this OS available we could 
use locally for compile tests?
Or alternatively, is there any free cross-toolchain available?


> ```
> configure: WARNING:
> This version of smartmontools does not use C++14, C++17 or C++20 
> enhancements,
> but future versions possibly will.
> This script was unable to determine a compiler option to enable C++20.
> Please send info about compiler and platform to
> smartmontools-support at listi.jpberlin.de - Thanks!

There are no plans to require C++20 very soon, but possibly C++14. So 
the above is good news.


> configure: WARNING:
> The OS/2 port of smartmontools is unmaintained.? Please report the test
> results to smartmontools-support at listi.jpberlin.de - Thanks!

Didn't expect such a quick feedback after I added the above message one 
week ago (88240355037d).

I will keep this message for a while but remove it for OS/2 (and keep 
QNX) before next release.


> ```
> Smartmontools compiled fine and seems to work fine.

Very good news, the recent "guessed" fix (20d527bc4a78) was apparently 
successful.


> I've attached the results of make check from the system's GCC, 9.2.0 
> and the latest available, 15.2.0. Not sure of other tests that I can do.

Did you test `smartctl -x -a ...`?

The os_os2.cpp module still uses the (meantime very) old interface which 
limits ATA pass-through to traditional SMART functionality. So `smartctl 
-x` will likely show many messages like:
"Non-SMART commands not implemented"

-- 
Thanks,
Christian


From dyeo at gmx.com  Wed Aug  5 00:52:43 2026
From: dyeo at gmx.com (Dave Yeo)
Date: Tue, 4 Aug 2026 15:52:43 -0700
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
 <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
Message-ID: <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>

Christian Franke wrote:
> Hi Dave,
>
> thanks for the positive feedback.
>
> Dave Yeo via Smartmontools-support wrote:
>> Hi, compiling the latest smartmontools git on ArcaOS (OEM version of
>> OS/2, arcanoae.com) configure output this at the tail,
>
> Is there any free (evaluation?) version of this OS available we could
> use locally for compile tests?

No. It is at heart OS/2 4.52, like eComStation (eCs), which did have an 
evaluation version available and there are 4.52 ISO's floating around 
the internet. Toolchain is installed as RPM's so can be installed on 
4.52 or updated on eCs

> Or alternatively, is there any free cross-toolchain available?
>

Yes, recently available. https://github.com/komh/cross-os2emx/ which 
should easily build smartmontools. Only available for Linux and Mac 
currently.

>
>> ```
>> configure: WARNING:
>> This version of smartmontools does not use C++14, C++17 or C++20
>> enhancements,
>> but future versions possibly will.
>> This script was unable to determine a compiler option to enable C++20.
>> Please send info about compiler and platform to
>> smartmontools-support at listi.jpberlin.de - Thanks!
>
> There are no plans to require C++20 very soon, but possibly C++14. So
> the above is good news.
>
>
>> configure: WARNING:
>> The OS/2 port of smartmontools is unmaintained.  Please report the test
>> results to smartmontools-support at listi.jpberlin.de - Thanks!
>
> Didn't expect such a quick feedback after I added the above message one
> week ago (88240355037d).

Good luck as I just happened to do a svn up and ended up with the git 
repository.

>
> I will keep this message for a while but remove it for OS/2 (and keep
> QNX) before next release.
>

Good. I'm now subscribed here so any support I can give.

>
>> ```
>> Smartmontools compiled fine and seems to work fine.
>
> Very good news, the recent "guessed" fix (20d527bc4a78) was apparently
> successful.
>
>
>> I've attached the results of make check from the system's GCC, 9.2.0
>> and the latest available, 15.2.0. Not sure of other tests that I can do.
>
> Did you test `smartctl -x -a ...`?

I tested -x and -a separately and now together. I'll attach the output 
from my HD. My SSD recently died, which is why I updated hoping a newer 
version would show some info. Unluckily it died with no SMART errors, 
seems to be the interface, sometimes detected during boot sometimes not.
Unluckily currently no smart support in the NVMe driver and most of my 
stuff on the NVMe drive.
I'll attach the output of smartctl -x -a ahci1

>
> The os_os2.cpp module still uses the (meantime very) old interface which
> limits ATA pass-through to traditional SMART functionality. So `smartctl
> -x` will likely show many messages like:
> "Non-SMART commands not implemented"
>

Surprisingly few, see log. Perhaps I should plug in an SSD to try?
Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smartctl.log
Type: application/x-log
Size: 7617 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/smartmontools-support/attachments/20260804/090b8d7e/attachment-0001.bin>

From Christian.Franke at t-online.de  Wed Aug  5 16:16:28 2026
From: Christian.Franke at t-online.de (Christian Franke)
Date: Wed, 5 Aug 2026 16:16:28 +0200
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
 <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
 <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>
Message-ID: <bdfaf411-239d-201b-2cda-3e98c9874544@t-online.de>

Dave Yeo wrote


> ...
>> Or alternatively, is there any free cross-toolchain available?
>>
>
> Yes, recently available. https://github.com/komh/cross-os2emx/ which 
> should easily build smartmontools. Only available for Linux and Mac 
> currently.

Thanks for the useful hint. It actually builds out of the box on Ubuntu 
26.04. I added this to one of our GH workflows.

If possible, please test the 'os2emx' artifact from the most recent run:
https://github.com/smartmontools/smartmontools/actions/workflows/build-manually.yml
Strings in the .exe suggest that the included libcn0.dll is required.

Fully static build did not work because the required libraries are not 
included in the package.
Build of the shared library (libsmartmon.dll) is apparently not 
supported by libtool on this platform.


>> ...
>> Did you test `smartctl -x -a ...`?
>
>> The os_os2.cpp module still uses the (meantime very) old interface which
>> limits ATA pass-through to traditional SMART functionality. So `smartctl
>> -x` will likely show many messages like:
>> "Non-SMART commands not implemented"
>>
>
> Surprisingly few, see log. Perhaps I should plug in an SSD to try?

Would not make much difference. The output looks as expected for this 
restricted subset of supported pass-through commands.

-- 
Thanks,
Christian


From dyeo at gmx.com  Wed Aug  5 18:13:27 2026
From: dyeo at gmx.com (Dave Yeo)
Date: Wed, 5 Aug 2026 09:13:27 -0700
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <bdfaf411-239d-201b-2cda-3e98c9874544@t-online.de>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
 <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
 <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>
 <bdfaf411-239d-201b-2cda-3e98c9874544@t-online.de>
Message-ID: <44b9d46e-4fe7-82ea-d768-ac3eeba098f7@gmx.com>

Christian Franke wrote:
> Dave Yeo wrote
>
>
>> ...
>>> Or alternatively, is there any free cross-toolchain available?
>>>
>>
>> Yes, recently available. https://github.com/komh/cross-os2emx/ which
>> should easily build smartmontools. Only available for Linux and Mac
>> currently.
>
> Thanks for the useful hint. It actually builds out of the box on Ubuntu
> 26.04. I added this to one of our GH workflows.
>
> If possible, please test the 'os2emx' artifact from the most recent run:
> https://github.com/smartmontools/smartmontools/actions/workflows/build-manually.yml
>
> Strings in the .exe suggest that the included libcn0.dll is required.

smartctl.exe runs fine here. It is big compared to the one I built, 
5.8MB compared to 1.1MB. I'd suggest using LDFLAGS=-Zomf in the 
configure arguments. GCC outputs aout objects on OS/2, the -Zomf calls 
emxomf to convert to OMF (obj) format and uses the system linker 
(OpenWatcom's wlink in this case) instead of the ancient ld, which is so 
old it is GPL v1 authored by RMS, with lots of updates over the years.

>
> Fully static build did not work because the required libraries are not
> included in the package.

Libc (libcn0.dll) is not available statically due to licensing. It is 
usually not packaged with binaries to make sure the system libcn0.dll is 
loaded. Weird bugs when an older libc is loaded by something before the 
system one as it is used globally.

> Build of the shared library (libsmartmon.dll) is apparently not
> supported by libtool on this platform.

Try --enable-shared --disable-static, should build smartmon.dll, or here 
smartmo0.dll. OS/2 is limited to 8.3 DLL naming. The lib prefix is also 
optional for static libs.
By default, configure only built a static library here, it is probably 
best to stick to static to avoid LIBPATH issues.
...
Dave

From Christian.Franke at t-online.de  Wed Aug  5 20:12:29 2026
From: Christian.Franke at t-online.de (Christian Franke)
Date: Wed, 5 Aug 2026 20:12:29 +0200
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <44b9d46e-4fe7-82ea-d768-ac3eeba098f7@gmx.com>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
 <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
 <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>
 <bdfaf411-239d-201b-2cda-3e98c9874544@t-online.de>
 <44b9d46e-4fe7-82ea-d768-ac3eeba098f7@gmx.com>
Message-ID: <47677270-1c5a-29e0-5282-5ef407e7abe0@t-online.de>

Dave Yeo wrote:
> ...
> smartctl.exe runs fine here. 

Thanks.


> It is big compared to the one I built, 5.8MB compared to 1.1MB.

This is because ./configure sets -g by default which adds plenty of 
debug info. The size without -g (aka after ...-strip) is reasonable:

$ i686-pc-os2-emx-size *.exe
 ?? text??? data???? bss???? dec???? hex filename
 ?864256?? 81920?? 77264 1023440?? f9dd0 smartctl.exe
 ?614400?? 61440?? 12768? 688608?? a81e0 smartd.exe

$ ls -1hs *.exe
5.6M smartctl.exe
4.2M smartd.exe

$ i686-pc-os2-emx-objdump -f smartctl.exe
smartctl.exe:???? file format a.out-emx
...

$ i686-pc-os2-emx-strip *.exe

$ ls -1hs *.exe
940K smartctl.exe
676K smartd.exe


> I'd suggest using LDFLAGS=-Zomf in the configure arguments. GCC 
> outputs aout objects on OS/2, the -Zomf calls emxomf to convert to OMF 
> (obj) format and uses the system linker (OpenWatcom's wlink in this 
> case) instead of the ancient ld, which is so old it is GPL v1 authored 
> by RMS, with lots of updates over the years.

$ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx LDFLAGS=-Zomf
$ make ...
$ cd src

$ ls -1hs *.exe
2.3M smartctl.exe
1.8M smartd.exe

$ i686-pc-os2-emx-strip *.exe
i686-pc-os2-emx-strip: smartctl.exe: file format not recognized
i686-pc-os2-emx-strip: smartd.exe: file format not recognized


$ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx 
CXXFLAGS=-O2 LDFLAGS=-Zomf
$ make ...
$ cd src

$ ls -1hs *.exe
1.5M smartctl.exe
1.2M smartd.exe

Not smaller than with aout.


>
>>
>> Fully static build did not work because the required libraries are not
>> included in the package.
>
> Libc (libcn0.dll) is not available statically due to licensing.

But it's packaged with the toolchain...


> It is usually not packaged with binaries to make sure the system 
> libcn0.dll is loaded.

I'll remove it from the artifact.


> Weird bugs when an older libc is loaded by something before the system 
> one as it is used globally.
>
>> Build of the shared library (libsmartmon.dll) is apparently not
>> supported by libtool on this platform.
>
> Try --enable-shared --disable-static, should build smartmon.dll, or 
> here smartmo0.dll.

Does not work for me:

 ? libtool: warning: undefined symbols not allowed in i686-pc-os2-emx 
shared libraries; building static only

This is as expected. After adding this to lib/Makefile (which as also 
required for the Windows DLL build)...

 ? libsmartmon_la_LDFLAGS = -no-undefined

... the result is:

emxbind: Invalid statement (line 1 of .libs/smartmon.def)
/opt/os2emx/bin/../lib/gcc/i686-pc-os2-emx/15/../../../../i686-pc-os2-emx/bin/ld: 
emxbind failed

$ head -2 lib/.libs/smartmon.def
LIBRARY smartmo0 INITINSTANCE TERMINSTANCEnDESCRIPTION "smartmon"nDATA 
MULTIPLE NONSHAREDnEXPORTSn? ; segment DATA32
"__ZN8smartmon12packet_typesE" ; magicseg='DATA32' len=28


Note that I use the upstream version of libtool[ize] because 
./autogen.sh is run under ubuntu to generate the source tarball.


> OS/2 is limited to 8.3 DLL naming.

Oh yes, I forgot, OS/2 usage is far too long ago (1994..2003). For which 
purposes is such an OS still in use today ?-)


> The lib prefix is also optional for static libs.
> By default, configure only built a static library here,

This is because I decided to start with LT_INIT([disable_shared]) when 
the library feature was added (1994d3316a0).


> it is probably best to stick to static to avoid LIBPATH issues.

Yes.

-- 
Thanks,
Christian


From dyeo at gmx.com  Thu Aug  6 04:42:22 2026
From: dyeo at gmx.com (Dave Yeo)
Date: Wed, 5 Aug 2026 19:42:22 -0700
Subject: [smartmontools-support] State of OS/2 port
In-Reply-To: <47677270-1c5a-29e0-5282-5ef407e7abe0@t-online.de>
References: <70ef0f99-d63a-c4c6-cb48-b8e270df7dff@gmx.com>
 <f517f8bc-cb6f-b95b-a5f8-0eb4bcba5655@t-online.de>
 <2aeb52d4-2428-e287-d570-f7aa15f658f9@gmx.com>
 <bdfaf411-239d-201b-2cda-3e98c9874544@t-online.de>
 <44b9d46e-4fe7-82ea-d768-ac3eeba098f7@gmx.com>
 <47677270-1c5a-29e0-5282-5ef407e7abe0@t-online.de>
Message-ID: <c7044953-5fc3-8727-e92f-224875939685@gmx.com>

Christian Franke wrote:
> Dave Yeo wrote:
>> ...
>> smartctl.exe runs fine here.
>
> Thanks.
>
>
>> It is big compared to the one I built, 5.8MB compared to 1.1MB.
>
> This is because ./configure sets -g by default which adds plenty of
> debug info. The size without -g (aka after ...-strip) is reasonable:
>
> $ i686-pc-os2-emx-size *.exe
>    text    data     bss     dec     hex filename
>  864256   81920   77264 1023440   f9dd0 smartctl.exe
>  614400   61440   12768  688608   a81e0 smartd.exe
>
> $ ls -1hs *.exe
> 5.6M smartctl.exe
> 4.2M smartd.exe
>
> $ i686-pc-os2-emx-objdump -f smartctl.exe
> smartctl.exe:     file format a.out-emx
> ...
>
> $ i686-pc-os2-emx-strip *.exe
>
> $ ls -1hs *.exe
> 940K smartctl.exe
> 676K smartd.exe

Ok, configure doesn't add -g here, also defaults to i386. Adding 
CXXFLAGS=-g -march=i686 gives me similar results

>
>
>> I'd suggest using LDFLAGS=-Zomf in the configure arguments. GCC
>> outputs aout objects on OS/2, the -Zomf calls emxomf to convert to OMF
>> (obj) format and uses the system linker (OpenWatcom's wlink in this
>> case) instead of the ancient ld, which is so old it is GPL v1 authored
>> by RMS, with lots of updates over the years.
>
> $ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx
> LDFLAGS=-Zomf
> $ make ...
> $ cd src
>
> $ ls -1hs *.exe
> 2.3M smartctl.exe
> 1.8M smartd.exe
>
> $ i686-pc-os2-emx-strip *.exe
> i686-pc-os2-emx-strip: smartctl.exe: file format not recognized
> i686-pc-os2-emx-strip: smartd.exe: file format not recognized

STRIP=emxomfstrip or perhaps =i686-pc-os2-emx-emxomfstrip
There's also lxlite which will also compress the binary by removing a 
lot of empty space as well as removing the debug info.

>
>
> $ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx
> CXXFLAGS=-O2 LDFLAGS=-Zomf
> $ make ...
> $ cd src
>
> $ ls -1hs *.exe
> 1.5M smartctl.exe
> 1.2M smartd.exe
>
> Not smaller than with aout.
>
>
>>
>>>
>>> Fully static build did not work because the required libraries are not
>>> included in the package.
>>
>> Libc (libcn0.dll) is not available statically due to licensing.
>
> But it's packaged with the toolchain...

Hmm, have to look. Maybe that ld and emxomfld refuse to statically link it.
KOMH has made quite a few changes, including to ld which may be why it 
is working well for you. He also got gdb working again with aout builds. 
For the longest time the only debuggers that worked were the IBM ones 
and another reason for needing -Zomf.

>
>
>> It is usually not packaged with binaries to make sure the system
>> libcn0.dll is loaded.
>
> I'll remove it from the artifact.

Good.

>
>
>> Weird bugs when an older libc is loaded by something before the system
>> one as it is used globally.
>>
>>> Build of the shared library (libsmartmon.dll) is apparently not
>>> supported by libtool on this platform.
>>
>> Try --enable-shared --disable-static, should build smartmon.dll, or
>> here smartmo0.dll.
>
> Does not work for me:
>
>   libtool: warning: undefined symbols not allowed in i686-pc-os2-emx
> shared libraries; building static only
>
> This is as expected. After adding this to lib/Makefile (which as also
> required for the Windows DLL build)...
>
>   libsmartmon_la_LDFLAGS = -no-undefined

Yes, forgot about upstream libtool often needing -no-undefined. 
Interestingly here, only needed it after add CXXFLAGS=-g -march=i686

>
> ... the result is:
>
> emxbind: Invalid statement (line 1 of .libs/smartmon.def)
> /opt/os2emx/bin/../lib/gcc/i686-pc-os2-emx/15/../../../../i686-pc-os2-emx/bin/ld:
> emxbind failed
>
> $ head -2 lib/.libs/smartmon.def
> LIBRARY smartmo0 INITINSTANCE TERMINSTANCEnDESCRIPTION "smartmon"nDATA
> MULTIPLE NONSHAREDnEXPORTSn  ; segment DATA32
> "__ZN8smartmon12packet_typesE" ; magicseg='DATA32' len=28

Yes, it is malformed, those n should be EOL,
K:\work\smartmontools\obj\lib\.libs>head -6 smartmo0.def
LIBRARY smartmo0 INITINSTANCE TERMINSTANCE
DESCRIPTION "smartmon"
DATA MULTIPLE NONSHARED
EXPORTS
   ; segment DATA32
   "__ZN8smartmon12packet_typesE" 
; magics
eg='DATA32' len=28

>
>
> Note that I use the upstream version of libtool[ize] because
> ./autogen.sh is run under ubuntu to generate the source tarball.

While usually use our port, which unluckily the maintainer doesn't try 
to get fixes upstream, regular libtool does usually work, sometimes 
needing -no-undefined as well as I use LDFLAGS=-Zomf
Upstream libtool is also more limited, can't pass a def file or handle 
declspec(export).

>
>
>> OS/2 is limited to 8.3 DLL naming.
>
> Oh yes, I forgot, OS/2 usage is far too long ago (1994..2003). For which
> purposes is such an OS still in use today ?-)

There are still instances running in back rooms in various enterprises, 
embedded devices and such, as well as hobbyist like me. Arca Noae seems 
to be making some money of it as if you want to run OS/2 on modern 
hardware, it is the only choice besides virtualization.

>
>
>> The lib prefix is also optional for static libs.
>> By default, configure only built a static library here,
>
> This is because I decided to start with LT_INIT([disable_shared]) when
> the library feature was added (1994d3316a0).
>
>
>> it is probably best to stick to static to avoid LIBPATH issues.
>
> Yes.
>

Thanks
Dave

From dyeo at gmx.com  Fri Aug  7 04:56:18 2026
From: dyeo at gmx.com (Dave Yeo)
Date: Thu, 6 Aug 2026 19:56:18 -0700
Subject: [smartmontools-support] Fix a minor irritation
Message-ID: <3bd5a99f-fdd2-0cd3-86e1-302d8c80c05a@gmx.com>

Hi, this fixes a minor irritation of mine when running smartctrl -h on OS/2.
I believe that using the AHCI driver is more common today then the older 
drivers.
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-the-help-output-on-OS-2-to-reflect-most-users.patch
Type: application/x-patch
Size: 1535 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/smartmontools-support/attachments/20260806/930a7502/attachment.bin>

From Christian.Franke at t-online.de  Fri Aug  7 12:03:46 2026
From: Christian.Franke at t-online.de (Christian Franke)
Date: Fri, 7 Aug 2026 12:03:46 +0200
Subject: [smartmontools-support] Fix a minor irritation
In-Reply-To: <3bd5a99f-fdd2-0cd3-86e1-302d8c80c05a@gmx.com>
References: <3bd5a99f-fdd2-0cd3-86e1-302d8c80c05a@gmx.com>
Message-ID: <f58768de-aa0d-1c39-f679-d43174e2218a@t-online.de>

Hi,

Dave Yeo via Smartmontools-support wrote:
> Hi, this fixes a minor irritation of mine when running smartctrl -h on 
> OS/2.
> I believe that using the AHCI driver is more common today then the 
> older drivers.

Pushed.

-- 
Thanks,
Christian


