Re: Bug reports, patches and other stuff
On Sep 12, Christopher C. Chimelis wrote:
>
> I'm already looking into some of these bugs and will update the tracking
> site as I make progress. I'm thinking about putting up a web page myself
> that lists the packages that are compiled already (hot-linked to the ftp
> site), but don't know if it's needed yet...any feedback anyone?
>
I was thinking about it myself (it's not handy to have to visit several
FTP sites just to decide whether I can use a binary or have to build it
from the source). However, Bdale convinced me that we should get all
our packages to master as soon as possible, and this would eliminate the
inconveniences caused by the absence of such a page.
> As far as the
> more binary, if you could, post it to my site with a patch and/or source
> and notify Pasi to replace the copy he included in base with yours.
There is absolutely no patch required to build a working more out of
util-linux-2.7.1. I've filed a bug report against util-linux (upgrade
request), so if the original maintainer releases util-linux-2.7.1 as a
Debian package, we'll be able to accommodate more on a more permanent
basis. I just feel it absolutely pointless to fix bugs in old versions
when newer versions that have already got the bugs fixed are available.
> Finally, regarding insmod, you say it's compiled under newer binutils? If
> so, is it feasible to upgrade the binutils package so that I can repackage
> module support? I would rather address the source of the problem rather
> than just tossing in a working binary temporarily.
I just did not try to recompile the modules/modutils/whatever package
myself to say whether it works or not... I am not 100% sure that the
problem with the current insmod is the binutils version, just 99%.
Current Debian binutils (2.8.1) should be OK, I've built my insmod under
much older binutils. I think building new modules support packages is
hopefully nothing more than just plain "debian/rules binary".
>
> I'm not going to get into a debate (as
> I've seen one develop already on this topic while I was gone), but I would
> say that anything that we have confirmed is working and stable SHOULD be
> uploaded to master ASAP.
Even maybe if it is not that working and stable...
> FYI, all I need to do now
> is have my PGP key verified and I'll have access to master, so alot of my
> packages will be there soon.
Great. Wonderful. For I doubt that my own registration as a Debian
maintainer is going to give any results.
>
> This has been fixed now by Pasi and also myself (we both did it but didn't
> know that each of us had done it separately :P). The new base disks will
> reflect the change. The only thing that needed to be changed was the way
> that "clock" was called. No kernel mods were needed (thank goodness).
>
Did you just add an option to specify -A if the system is going to be
booted from ARC? Certainly it's a solution, although, in my opinion,
not quite perfect. Because:
1. Digital UNIX (at least starting from v4.0) adds 1952 to the clock
settings. This does not fit into the current scheme, if we are going to
dual boot and keep Digital UNIX happy.
2. The clock program is patched by Alpha patches almost to death. It is
a nightmare to re-apply these patches to every new release of util-linux.
3. These patches are so ugly that the util-linux maintainers reject to
incorporate them into the official sources.
4. The access method utilised by clock is not SMP-safe.
5. There is no clock program in the newest util-linux package, it has
been superceded by hwclock.
The proposed way to work with the hardware clock is to do it through the
/dev/rtc because:
1. It is the only potentially SMP-safe method.
2. It is directly supported by hwclock (no Alpha-specific patches needed).
3. It is ridiculous to do a direct device access (bypassing the kernel)
under an OS that claims to be Unix-like. It is especially ridiculous on
Alphas where this cannot even be done in a system-independent manner
(clock has to determine the system type at run time e.g. because the
hardware clock has different port address on a Jensen, etc.).
The problem with /dev/rtc is that this driver is broken under normal
2.0.x kernels. A simple fix is included with the standard
alpha-patches, though.
A note about epochs. Since the hardware clock features only one byte to
keep the year number, a conversion should be made to get the real year
from the chip. The on-chip register increments once a year, so the
required conversion is an addition of some number to the value of
the register. This value is called epoch (so epoch is the year when the
chip shows 0).
There is no common opinion in the Alpha world on what the epoch should
be. Windows NT uses 1980, Digital UNIX - 1952, Linux (following the
DOS/PC tradition) - 1900 (or sometimes 2000).
With the currently adopted scheme, the user must explicitly specify
whether the system is booted from ARC or not. This may seem simple, but
just have a look at the archive of axp-list@redhat.com! The number of
questions "why 2017" is very impressive. But the epochs are easily
autodetectable, we can totally remove all this hassle from both users
and system installation programs just by writing some autodetection code.
The question now is, where to put this code. It seems natural to put it
into the clock interface program, /sbin/clock or /sbin/hwclock. Like it
is approached now by the ugly -A switch to /sbin/clock. However, the
/dev/rtc driver's interface operates in terms of struct tm (years,
months, days, etc.) rather than of raw MC146818 registers. It means
that an epoch-dependent year conversion is already performed in the
kernel. It may not be a brilliant solution, but that is how it
currently works. (I'm not fond of this myself.) This dictates that all
the epoch dependency should go into the kernel. Putting a little bit
(quite little, beleive me) of epoch support code into the kernel does
not break anything. Changing the well-established /dev/rtc interface,
unfortunately, would be a disaster.
> Also, regarding the kernel, my personal feeling is that if we need to
> patch the kernel, then we should submit the patches for modification of
> the kernel sources by "the powers that be".
I strongly agree, and I'm sure that is not only your personal feeling.
Of course, we are not going to introduce proprietary kernel patches
unless it is strictly necessary. All the proposed modification must be
submitted to the "upstream maintainers".
> Have your patches and Jay's patches been accepted for 2.0.31?
No, they haven't. And I doubt they ever will. The axp-patches, which
have evolved into alpha-patches, have been around since 1.3.x. They
never managed to get their way into the official kernel sources,
probably because the main development is going on with 2.1.x; nobody is
interested in patching 2.0. However, alpha-patches are a quite official
patchset for 2.0.x/alpha, so I'll better submit my patches to Jay.
Nikita
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: