Linux-2.5.14..
Linus Torvalds
There's a lot of stuff that has happened in the 2.5.x series lately, and
you can see the gory details in the ChangeLog files that accompany
releases these days, but I thought I'd point out 2.5.14, since it has some
interesting fundamental changes to how dirty state is maintained in the
VM.
(The big changes were actually in 2.5.12, but 2.5.13 contained various
minor fixes and tweaks, and 2.5.14 contains a number of fixes especially
wrt truncate, so hopefully it's fairly _stable_ as of 2.5.14.)
Credit goes to Andrew Morton, and not only does it clean up the code a
lot, it also seems to perform a lot better in many circumstances.
There's a lot of other stuff in the 2.5.x tree too, but few things are so
fundamental. Please test (but also, please be careful - backups are always
a good idea).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Daniel Pittman
> There's a lot of stuff that has happened in the 2.5.x series lately,
> and you can see the gory details in the ChangeLog files that accompany
> releases these days, but I thought I'd point out 2.5.14, since it has
> some interesting fundamental changes to how dirty state is maintained
> in the VM.
>
> (The big changes were actually in 2.5.12, but 2.5.13 contained various
> minor fixes and tweaks, and 2.5.14 contains a number of fixes
> especially wrt truncate, so hopefully it's fairly _stable_ as of
> 2.5.14.)
From the look of the changelog at least a few of the file corruption
bugs with ext3, 2k block file systems and 2.5 have been fixed. Should I
expect this release to address the problems I was seeing?
Daniel
--
I keep my head above the surface, trying to breath, looking for land.
I keep an eye at the distant horizon waiting for help, clutching the sky.
-- Covenant, _Phoenix_
bert hubert
> releases these days, but I thought I'd point out 2.5.14, since it has some
> interesting fundamental changes to how dirty state is maintained in the
> VM.
I parsed this 'dirty state' sentence all wrong at first :-) Andrew, Linus -
where does the current VM lie in between rmap-vm and aa-vm?
Regards,
bert hubert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Andrew Morton
>
> On Sun, 5 May 2002, Linus Torvalds wrote:
> > There's a lot of stuff that has happened in the 2.5.x series lately,
> > and you can see the gory details in the ChangeLog files that accompany
> > releases these days, but I thought I'd point out 2.5.14, since it has
> > some interesting fundamental changes to how dirty state is maintained
> > in the VM.
> >
> > (The big changes were actually in 2.5.12, but 2.5.13 contained various
> > minor fixes and tweaks, and 2.5.14 contains a number of fixes
> > especially wrt truncate, so hopefully it's fairly _stable_ as of
> > 2.5.14.)
>
> >From the look of the changelog at least a few of the file corruption
> bugs with ext3, 2k block file systems and 2.5 have been fixed. Should I
> expect this release to address the problems I was seeing?
>
I don't have an explanation for the ext3 problem which you saw.
It's conceivable that 2.5.13 was leaving dirty buffers around after
they were "deleted", and that fsync grabbed them via the i_dirty_buffers
back door, and wrote them where they shouldn't have been written.
But they wouldn't have been mapped anywhere...
So I still need to try to reproduce that one. If you could have
another shot, it would be appreciated. But if it _does_ work OK,
I can't say it's fixed until I know what caused the 2.4.13 failure.
ext3 is very sensitive to what is going on in buffer.c. There's
a lot of tension in there between the desire to share code and
the desire to not be damaged by changes in the code which we share.
Generally, ext3 with data=journal is not happy at present.
Partly because it contains assertions of things which aren't true
any more.
Partly because of a known problem in ext3: assertion failure at
transaction.c:606. Stephen has a fix for this which we need to
wiggle into 2.4. For some reason, the 2.5 changes are triggering
it much more easily.
I'll spend a few hours this week trying to resurrect data=journal,
but if that doesn't work out I think I'll just turn it off for the
while, make it emit a warning and use data=ordered.
-
Andrew Morton
>
> On Mon, May 06, 2002 at 03:54:46AM +0000, Linus Torvalds wrote:
>
> > releases these days, but I thought I'd point out 2.5.14, since it has some
> > interesting fundamental changes to how dirty state is maintained in the
> > VM.
>
> I parsed this 'dirty state' sentence all wrong at first :-) Andrew, Linus -
> where does the current VM lie in between rmap-vm and aa-vm?
>
"VM" is a broad term. The memory allocator, page replacement, swap and
all that stuff is unaltered - it is the same as 2.4.current. ie: Andrea's
VM from when his changes stopped going into the mainline kernel.
I made minimal changes in there to teach the page allocator that
all dirty memory is written back via pages and not sometimes-pages,
sometimes-buffers. Also to add support for the new `clustering
writeback' which address_spaces can perform.
It's probably not as well tuned as it could be at present, but
I don't see a lot of point in fiddling with it. As long as the
VM doesn't actually impede 2.5 development and evaulation of
2.5 performance, best to leave it alone until a VM developer
steps up to do the 2.6 VM.
The change to which Linus refers is:
In 2.4, dirty data from the write(2) system call is encapsulated
in buffer_heads and is placed on a global buffer list for writeout.
And dirty data from shared mappings is attached to its inode.
In 2.5, the buffer list went away, and dirty data from write(2)
is now managed in the same way as dirty data from mmap().
And because the kupdate and bdflush functions used to work
against the buffer LRU, replacements were introduced which do
the same thing against the inodes, instead of against the buffers.
So it's all page-oriented now.
-
Rik van Riel
> bert hubert wrote:
> > I parsed this 'dirty state' sentence all wrong at first :-) Andrew, Linus -
> > where does the current VM lie in between rmap-vm and aa-vm?
> I made minimal changes in there to teach the page allocator that
> all dirty memory is written back via pages and not sometimes-pages,
> sometimes-buffers. Also to add support for the new `clustering
> writeback' which address_spaces can perform.
> So it's all page-oriented now.
Nice, this will make it possible to have much cleaner page
replacement code.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Linus Torvalds
On Mon, 6 May 2002, Daniel Pittman wrote:
>
> From the look of the changelog at least a few of the file corruption
> bugs with ext3, 2k block file systems and 2.5 have been fixed. Should I
> expect this release to address the problems I was seeing?
"Expect" is too strong a word. I'd say "hope" - a number of truncate bugs
were fixed, but whether that was what bit you, nobody knows.
I suspect the real answer is that we'd love for you to test things out,
but that if it ends up being too painful to recover if the problems happen
again, you probably shouldn't..
Linus
Daniel Pittman
> On Mon, 6 May 2002, Daniel Pittman wrote:
>>
>> From the look of the changelog at least a few of the file corruption
>> bugs with ext3, 2k block file systems and 2.5 have been fixed. Should
>> I expect this release to address the problems I was seeing?
>
> "Expect" is too strong a word. I'd say "hope" - a number of truncate
> bugs were fixed, but whether that was what bit you, nobody knows.
Well, hope seems justified...
> I suspect the real answer is that we'd love for you to test things
> out, but that if it ends up being too painful to recover if the
> problems happen again, you probably shouldn't..
I did, and I failed to reproduce it working on a scratch disk. This was
a period of playing and I /hope/ that it's conclusive. I couldn't get
.12 to reliably fail, though, which is less inspiring.
I should be able to find some time in the next day or so to test it a
bit more on the scratch disk and then, if that works, I will update my
backups. :)
Still, it seems good so far.
Daniel
--
Television is the ideal propaganda medium, a mendacious monster, not primarily
out of malice but from its amoral nature.
-- Paul Johnson
Martin Dalecki
- Push poll_timeout down from the hwgroup to the channel. We are resetting the
channel and not a whole hwgroup. This way using multiple pdc202xxx cards
should magically start to work with multiple performance and resets will no
longer lock the system.
- Updates for PDC4030 by Peter Denison <pet...@marshadder.uklinux.net>.
- Make ide_raw_taskfile don't care about request buffers. They where always
NULL.
- Port set multi mode count over from the special setting interface to
ide_raw_taskfile. Fix errors in the corresponding interrupt handler in one go
as well. It turned out that this is precisely the same code as in
task_no_data_intr, so we can nuke it altogether. And finally we have found
some problems with the set_pio_mode() command which can fail with -EBUSY -
this is in esp. probably *very* common during boot hdparm usage those days!
(OK it was masked by reportig too early that it finished... Crap Crap utter
crap it was!!!) Right now hdparm should just be extendid to properly
sync and retry on -EBUSY and everything should be fine.
And now the 1 Milion EUR question for everybody who loves to put driver
settings in to /proc:
How the hell could echo > /proc/ide/ide0/settings blah blah blah blah handle
properly cases like -EIO, -EBUSY and so on??? Having the possibility o do it
does not mean that it is a good idea to use it.
OK. After realizing the simple fact that quite a lot of low level hardware
manipulating ioctls may require assistance in usage from proper logic which is
*very* unlikely to be implemented in a bash (for me preferable still ksh) I
have made my mind up.
/proc/ide will be nuked.
- Execute the recalibration for error recovery on precisely the same request as
the one which failed.
- Remove set geometry. It's crap by means of standard specification. Because:
1. We relay on the existence of the identify command anyway.
2. This command was obsoleted *before* the identify command existed as far
as I can see.
2. I'm able to have a look at what other ATA/ATAPI drivers in the wild do:
They don't do it.
- Just call tuneproc in set_pio_mode() directly - we are already behind the rq
queue there.
- After we have uncovered the broken logics behind the whole ioctl handling we
now just have made ide_spin_wait_hwgroup() waiting for a proper somehow
longer timeout before giving up. This was previously just hiding the broken
concept of setting ioctl values through /proc/ide/ideX/settings - now it just
really helps hdparm to not to give up too early. (It shouldn't probably play
wreck havock on the global driver spin lock as well. I will look in to this
later.)
- Scrap the non necessary, to say the least, disabling of interrupts for 3,
read it again please, 3 seconds, on the local CPU inside
ide_spin_wait_hwgroup(). Spin lock handling needs checking there badly as I
see now as well...
Hey apparently any "special" requests are gone. We now have only
to deal with REQ_DEVICE_ACB and REQ_DEVICE_CMD. One of them is still too
much and will be killed.
Martin Dalecki
Nuke /proc/ide. For explanations why, please see the frustrated comments in the
previous change log. If one still don't see why it wasn't a good thing,
well please just take a look at the following:
Kernel size before:
/usr/src/linux# size vmlinux
text data bss dec hex filename
1716049 403968 470252 2590269 27863d vmlinux
/usr/src/linux#
Kernel size after:
/usr/src/linux# size vmlinux
text data bss dec hex filename
1680993 403488 470124 2554605 26faed vmlinux
/usr/src/linux#
2% of overall size! And this is not exactly an minimalistic setup.
Wow! What a waste of space!!!! Not even counting the runtime size
of this crap! And then let's take a look at the following self
flattery:
-/*
- * Copyright (C) 1997-1998 Mark Lord
- *
- * This is the /proc/ide/ filesystem implementation.
- *
- * The major reason this exists is to provide sufficient access
- * to driver and config data, such that user-mode programs can
- * be developed to handle chipset tuning for most PCI interfaces.
- * This should provide better utilities, and less kernel bloat.
^^^^^^^^^^^^^^^^^^
Well there could only be an answer to this which would be
universally understandable in every Slavic language... but since
it's mothers day...
EOD.
Anton Altaparmakov
>Tue May 7 02:37:49 CEST 2002 ide-clean-57
>
>Nuke /proc/ide. For explanations why, please see the frustrated comments
>in the previous change log.
This is a big mistake IMO.
Nuking the ability to change settings, fair enough, but only if alternative
interface is provided for userspace to tweak everything, otherwise provide
the interface before you remove the existing one. (There may be already
another interface, I don't know...I am sure someone will tell me if there is!)
Removing the information provided by /proc/ide is very bad! It is very
useful to diagnose one's ide setup, to see what the host is configured as,
what all settings are set to, etc. This is the first place I look to check
whether the interfaces are configured as I expect them to be and in case of
problems, this is again the first place I look.
What alternatives are you going to present to give all the information that
/proc/ide gives? If the answer is none IMHO your patch is not acceptable...
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Martin Dalecki
> At 12:27 07/05/02, Martin Dalecki wrote:
>
>> Tue May 7 02:37:49 CEST 2002 ide-clean-57
>>
>> Nuke /proc/ide. For explanations why, please see the frustrated
>> comments in the previous change log.
>
>
> This is a big mistake IMO.
>
> Nuking the ability to change settings, fair enough, but only if
> alternative interface is provided for userspace to tweak everything,
> otherwise provide the interface before you remove the existing one.
> (There may be already another interface, I don't know...I am sure
> someone will tell me if there is!)
Ehmm... There *is* one interface there. hdparm will help
you. Note: the upcomming release of hdparm should contain the
following patch which incearses it's usability vastly to the
average user. Just for convenience I'm attaching it here.
If you don't like hdparm - well please shoot the
people who wrote init, ifconfig, eject and so on...
Mikael Pettersson
> Uz.ytkownik Anton Altaparmakov napisa?:
> > At 12:27 07/05/02, Martin Dalecki wrote:
> >
> >> Tue May 7 02:37:49 CEST 2002 ide-clean-57
> >>
> >> Nuke /proc/ide. For explanations why, please see the frustrated
> >> comments in the previous change log.
> >
> >
> > This is a big mistake IMO.
> >
> > Nuking the ability to change settings, fair enough, but only if
> > alternative interface is provided for userspace to tweak everything,
> > otherwise provide the interface before you remove the existing one.
> > (There may be already another interface, I don't know...I am sure
> > someone will tell me if there is!)
>
> Ehmm... There *is* one interface there. hdparm will help
> you. Note: the upcomming release of hdparm should contain the
hdparm -i requires root privs. cat /proc/ide/${file} does not.
hdparm is NOT an acceptable substitute for /proc/ide/.
/Mikael
Anton Altaparmakov
>Uz.ytkownik Anton Altaparmakov napisa?:
>>At 12:27 07/05/02, Martin Dalecki wrote:
>>>Tue May 7 02:37:49 CEST 2002 ide-clean-57
>>>
>>>Nuke /proc/ide. For explanations why, please see the frustrated comments
>>>in the previous change log.
>>
>>This is a big mistake IMO.
>>Nuking the ability to change settings, fair enough, but only if
>>alternative interface is provided for userspace to tweak everything,
>>otherwise provide the interface before you remove the existing one.
>>(There may be already another interface, I don't know...I am sure someone
>>will tell me if there is!)
>
>Ehmm... There *is* one interface there. hdparm will help
>you. Note: the upcomming release of hdparm should contain the
>following patch which incearses it's usability vastly to the
>average user. Just for convenience I'm attaching it here.
How do I get this information with hdparm please?
[aia21@drop ide]$ cat via
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.34
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
Highest DMA rate: UDMA100
BM-DMA base: 0xd000
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes no
Post Write Buffer: yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: UDMA PIO DMA UDMA
Address Setup: 30ns 120ns 30ns 30ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 90ns
Data Recovery: 30ns 270ns 30ns 30ns
Cycle Time: 20ns 600ns 120ns 60ns
Transfer Rate: 99.9MB/s 3.3MB/s 16.6MB/s 33.3MB/s
hdparm is a tool to query a device and how the controller is programmed to
talk to the device. But it is not designed nor capable of giving
information about the host itself. I just read the man page for hdparm and
there are no options in sight to show any of the things I have shown above.
Also the below work as normal user but hdparm requires super user... It is
debateable whether a normal user should be allowed access but still you are
taking away existing functionality...
[aia21@drop hda]$ cat cache
1916
[aia21@drop hda]$ cat capacity
80418240
[aia21@drop hda]$ cat geometry
physical 79780/16/63
logical 5005/255/63
And hdparm never gives you the physical geometry AFAICS.
Either I am missing something or you are removing a lot of functionality
and replacing it with nothingness...
And as I said, I can understand removing the ability to write values into
/proc/ide/*, what I disagree with is the removal of the information
provided by read-only access to /proc/ide/*. And that is because I am not
aware of any other way to get the same information.
Padraig Brady
> Mon May 6 13:29:44 CEST 2002 ide-clean-56
>
[snip]
> OK. After realizing the simple fact that quite a lot of low level
> hardware manipulating ioctls may require assistance in usage from
> proper logic which is *very* unlikely to be implemented in a bash
> (for me preferable still ksh) I have made my mind up.
>
> /proc/ide will be nuked.
Please consider this carefully, especially the read only bits.
One particular thing I use a lot is: /proc/ide/hda/capacity
Will there be another interface easily usable by scripts
to get this information?
Am I going to have to parse hdparm output?
....
geometry = 2434/255/63, sectors = 39102336, start = 0
Am I going to need hdparm on my embedded system?
Padraig.
Dave Jones
> hdparm -i requires root privs.
hdparm itself doesn't, but you must be able to read /dev/hd*
Some distros have this owned by group 'disk' for eg.
Adding yourself as a member of this group should allow you to
use hdparm without becoming root.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones
> How do I get this information with hdparm please?
>
> [aia21@drop ide]$ cat via
Bartlomiej Zolnierkiewicz moved all this stuff to userspace
a long time ago in 'ideinfo'.
> [aia21@drop hda]$ cat cache
> 1916
> [aia21@drop hda]$ cat capacity
> 80418240
> [aia21@drop hda]$ cat geometry
> physical 79780/16/63
> logical 5005/255/63
>
> And hdparm never gives you the physical geometry AFAICS.
Why would a normal user ever need to know this info?
> And as I said, I can understand removing the ability to write values into
> /proc/ide/*, what I disagree with is the removal of the information
> provided by read-only access to /proc/ide/*. And that is because I am not
> aware of any other way to get the same information.
The parsing gunk we have for /proc/ide is fugly, and should have been
done with sysctls from day one imo.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Martin Dalecki
> On Tue, May 07, 2002 at 02:57:46PM +0100, Anton Altaparmakov wrote:
> > How do I get this information with hdparm please?
> >
> > [aia21@drop ide]$ cat via
>
> Bartlomiej Zolnierkiewicz moved all this stuff to userspace
> a long time ago in 'ideinfo'.
>
> > [aia21@drop hda]$ cat cache
> > 1916
> > [aia21@drop hda]$ cat capacity
> > 80418240
> > [aia21@drop hda]$ cat geometry
> > physical 79780/16/63
> > logical 5005/255/63
> >
> > And hdparm never gives you the physical geometry AFAICS.
>
> Why would a normal user ever need to know this info?
>
> > And as I said, I can understand removing the ability to write values into
> > /proc/ide/*, what I disagree with is the removal of the information
> > provided by read-only access to /proc/ide/*. And that is because I am not
> > aware of any other way to get the same information.
>
> The parsing gunk we have for /proc/ide is fugly, and should have been
> done with sysctls from day one imo.
Amen. For where it turn outs to be really really worth it
I indeed plan to move to sysctl. For example currently
we have on ioctl level still the problem that many of
them are attached to the device but act on the channel.
hdparm -xxx /dev/hda & hdparm -xxx /dev/hdc - BANG race condition.
(At least on the level of logics).
Martin Dalecki
> Am I going to have to parse hdparm output?
> ....
> geometry = 2434/255/63, sectors = 39102336, start = 0
>
> Am I going to need hdparm on my embedded system?
Yes. Or just fsck hardcode the defaults.
Anton Altaparmakov
>On Tue, May 07, 2002 at 02:57:46PM +0100, Anton Altaparmakov wrote:
> > How do I get this information with hdparm please?
> >
> > [aia21@drop ide]$ cat via
>
>Bartlomiej Zolnierkiewicz moved all this stuff to userspace
>a long time ago in 'ideinfo'.
[aia21@drop hda]$ ideinfo
bash: ideinfo: command not found
Obviously distros haven't caught up with this development. )-:
Care to give me a URL? A quick google for "ideinfo Linux download" didn't
bring up anything looking relevant.
> > [aia21@drop hda]$ cat cache
> > 1916
> > [aia21@drop hda]$ cat capacity
> > 80418240
> > [aia21@drop hda]$ cat geometry
> > physical 79780/16/63
> > logical 5005/255/63
> >
> > And hdparm never gives you the physical geometry AFAICS.
>
>Why would a normal user ever need to know this info?
I want to know this info. (-: Admittedly normal users don't need it... It
is useful for diagnosing problems with NTFS and MD setups for example (in
conjunction with fdisk -l shown in sectors).
> > And as I said, I can understand removing the ability to write values into
> > /proc/ide/*, what I disagree with is the removal of the information
> > provided by read-only access to /proc/ide/*. And that is because I am not
> > aware of any other way to get the same information.
>
>The parsing gunk we have for /proc/ide is fugly, and should have been
>done with sysctls from day one imo.
I like text parsing... It is not performance critical and makes info human
readable... Whether existing text parsers are any good or not, I don't
care, write a better one if you don't like the existing one or go beat up
the people who wrote the bad ones... That seems to be Martin's standard
reply, so I thought I would use it, too. (-;
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
Padraig Brady
> Uz.ytkownik Padraig Brady napisa?:
>
>> Am I going to have to parse hdparm output?
>> ....
>> geometry = 2434/255/63, sectors = 39102336, start = 0
>>
>> Am I going to need hdparm on my embedded system?
>
>
> Yes. Or just fsck hardcode the defaults.
>
hardcode defaults?
Also are the following standard RH7.1 programs going to
need changing?
[padraig@pixelbeat padraig]$ find /sbin /usr/sbin /bin /usr/bin /lib
/usr/lib /usr/bin/X11/ -xdev -perm +111 | xargs grep -l /proc/ide
2>/dev/null
/sbin/mkinitrd
/sbin/fdisk
/sbin/sfdisk
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/Xconfigurator
Padraig.
Martin Dalecki
>
> [aia21@drop hda]$ ideinfo
> bash: ideinfo: command not found
>
> Obviously distros haven't caught up with this development. )-:
>
> Care to give me a URL? A quick google for "ideinfo Linux download"
> didn't bring up anything looking relevant.
http://www.j2.ru/frozenfido/ru.unix.bsd/1329707b3e3f8.html
Porting it should be fairly tirvial. Basically lspci +
the parsing crap.
>
> I like text parsing... It is not performance critical and makes info
> human readable... Whether existing text parsers are any good or not, I
> don't care, write a better one if you don't like the existing one or go
> beat up the people who wrote the bad ones... That seems to be Martin's
> standard reply, so I thought I would use it, too. (-;
Feel free to do it yourself - in user space where it belongs.
Anton Altaparmakov
>>Am I going to have to parse hdparm output?
>>....
>> geometry = 2434/255/63, sectors = 39102336, start = 0
>>Am I going to need hdparm on my embedded system?
>
>Yes. Or just fsck hardcode the defaults.
This is stupid! And if that isn't obvious to you, you should think a bit
more carefully...
Linux's power is exactly that it can be used on anything from a wristwatch
to a huge server and that it is flexible about everything. You are breaking
this flexibility for no apparent reason. (I don't accept "I can't cope with
this so I remove it." as a reason, sorry).
As the new IDE maintainer so far we have only seen you removing one feature
after the other in the name of cleanup, without adequate or even any at
all(!) replacements, renaming all functions to hell and back, and breaking
the ide core here there and everywhere. All critical bug fixes seem to have
been contributed by other people looking at your code which doesn't inspire
a lot of confidence in you... Even Alan Cox said a while ago that you have
his vote of no confidence (probably slightly rephrased here) because of
changes you were introducing and I tend to trust bearded kernel hackers
from Whales. (-;
Aren't you noticing that something is wrong here???
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
Padraig Brady
> On Tue, May 07, 2002 at 02:57:46PM +0100, Anton Altaparmakov wrote:
> > How do I get this information with hdparm please?
> >
> > [aia21@drop ide]$ cat via
>
> Bartlomiej Zolnierkiewicz moved all this stuff to userspace
> a long time ago in 'ideinfo'.
>
> > [aia21@drop hda]$ cat cache
> > 1916
> > [aia21@drop hda]$ cat capacity
> > 80418240
> > [aia21@drop hda]$ cat geometry
> > physical 79780/16/63
> > logical 5005/255/63
> >
> > And hdparm never gives you the physical geometry AFAICS.
>
> Why would a normal user ever need to know this info?
Well one application we have here is a backup script in a web
interface (php running as nobody), which copies a whole disk
(compact flash) to the client while indicating the total size
to the client for feedback:
Header("Content-type: application/octet-stream");
$flash_size=`cat /proc/ide/hda/capacity`;
$flash_size=$flash_size*512;
Header("Content-length: $flash_size");
Header("Content-Disposition: attachment; filename=flash.img");
passthru("/bin/suid_copy_flash");
Now you could of course have a /bin/suid_get_flash_size
but this is messy/less efficient?
Padraig.
Anton Altaparmakov
>Uz.ytkownik Anton Altaparmakov napisa?:
>>[aia21@drop hda]$ ideinfo
>>bash: ideinfo: command not found
>>Obviously distros haven't caught up with this development. )-:
>>Care to give me a URL? A quick google for "ideinfo Linux download" didn't
>>bring up anything looking relevant.
>
>http://www.j2.ru/frozenfido/ru.unix.bsd/1329707b3e3f8.html
>
>Porting it should be fairly tirvial. Basically lspci +
>the parsing crap.
I don't want to port anything. I don't know ide and I don't want to know
ide. I want to be able to use it. I am an ide USER. You are the ide
DEVELOPER. If you take away functionality YOU have to provide a
replacement. NOT tell me, the USER to write it.
>>I like text parsing... It is not performance critical and makes info
>>human readable... Whether existing text parsers are any good or not, I
>>don't care, write a better one if you don't like the existing one or go
>>beat up the people who wrote the bad ones... That seems to be Martin's
>>standard reply, so I thought I would use it, too. (-;
>
>Feel free to do it yourself - in user space where it belongs.
I don't want to do it myself. I want YOU to do it because YOU are taking
away the functionality that already exists.
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
Linus Torvalds
[ First off: any IDE-only thing that doesn't work for SCSI or other disks
doesn't solve a generic problem, so the complaint that some generic
tools might use it is totally invalid. ]
On Tue, 7 May 2002, Anton Altaparmakov wrote:
>
> Linux's power is exactly that it can be used on anything from a wristwatch
> to a huge server and that it is flexible about everything. You are breaking
> this flexibility for no apparent reason. (I don't accept "I can't cope with
> this so I remove it." as a reason, sorry).
Run the 57 patch, and complain if something doesn't work.
Linux's power is that we FIX stuff. That we make it the best system
possible, and that we don't just whine and argue about things.
> As the new IDE maintainer so far we have only seen you removing one
> feature after the other in the name of cleanup, without adequate or even
> any at all(!) replacements,
Who cares? Have you found _anything_ that Martin removed that was at all
worthwhile? I sure haven't.
Guys, you have to realize that the IDE layer has eight YEARS of absolute
crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
so distasteful that t's scary.
Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
code. You can do it yourself if you want to. You don't need a maintainer
to add barnacles.
All the information that /proc/ide gave you is basically available in
hdparm, and for your dear embedded system it apparently takes up less
space by being in user space. So what is the problem?
My vote is to remove as much as humanly possible.
"Everything should be made as simple as possible, but not
simpler" - Albert Einstein
Think about it, and really _understand_ it.
Linus
Martin Dalecki
- Apply m68k fixes by Roman Zippel.
- Apply CDROM PIO mode fix by Osamu Tamita.
(You are true "Hawk-eye" hovering over my head! Respect - and many Thanks.)
- Virtualize the udma_enable method as well to help ARM and PPC people. Please
please if you would like to have some other methods virtualized in a similar
way - just tell me or even better do it yourself at the end of ide-dma.c.
I *don't mind* patches.
- Fix the pmac code to adhere to the new API. It's supposed to work again.
However this is blind coding... I give myself 80% chances for it to work ;-).
Jan Harkes
> On Tue, 7 May 2002, Anton Altaparmakov wrote:
> > As the new IDE maintainer so far we have only seen you removing one
> > feature after the other in the name of cleanup, without adequate or even
> > any at all(!) replacements,
>
> Who cares? Have you found _anything_ that Martin removed that was at all
> worthwhile? I sure haven't.
I'm still hoping a patch will show up that will allow me to regain
access to my compactflash cards and IBM microdrive disks. The code
currently doesn't rescan for new drives when a card has been inserted,
although it still seems to have all the necessary logic.
Jan
Martin Dalecki
> On Tue, May 07, 2002 at 08:36:54AM -0700, Linus Torvalds wrote:
>
>>On Tue, 7 May 2002, Anton Altaparmakov wrote:
>>
>>>As the new IDE maintainer so far we have only seen you removing one
>>>feature after the other in the name of cleanup, without adequate or even
>>>any at all(!) replacements,
>>
>>Who cares? Have you found _anything_ that Martin removed that was at all
>>worthwhile? I sure haven't.
>
>
> I'm still hoping a patch will show up that will allow me to regain
> access to my compactflash cards and IBM microdrive disks. The code
> currently doesn't rescan for new drives when a card has been inserted,
> although it still seems to have all the necessary logic.
>
Yes I'm fully aware of this, but the whole initialization
is currently much in flux and I will return to this issue back
if I think that things are in shape there. OK?
Padraig Brady
Well my "dear" embedded system doesn't have libc :-(
So 35664 saved in kernel (less on disk), requires 25212
extra for hdparm + more for static linked uclibc (hope
it works ;-)). As a side note if this happens hdparm would
be a requirement for busybox IMHO, anyway getting back on topic...
All the info I've ever needed is /proc/ide/hdx/capacity
which I could get from /proc/partitions with more a bit
more effort, so I vote for removing /proc/ide.
I think everyone realises Martin is doing great and much needed work
on IDE (btw I'll have those flash support patches soon Martin ;-)),
but I did think this change needed debate. In general I know it's a
hard decision what to export in proc, especially if there are
existing dependencies, a few already mentioned possibles in RH7.1:
/sbin/mkinitrd
/sbin/fdisk
/sbin/sfdisk
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/Xconfigurator
For e.g. could the same arguments could be made for lspci only
interface to pci info rather than /proc/bus/pci? The following
references are made to /proc/bus/pci on my system:
/sbin/lspci
/sbin/setpci
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/sbin/adsl-config
/usr/sbin/internet-config
/usr/sbin/isdn-config
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/XFree86
/usr/bin/X11/pcitweak
/usr/bin/X11/scanpci
/usr/bin/X11/Xconfigurator
cheers,
Padraig.
Alan Cox
> which I could get from /proc/partitions with more a bit
> more effort, so I vote for removing /proc/ide.
/proc/ide has useful information in it that you can't get easily by
other means at the moment - which controller is driving the disks, what
devices are present etc.
> For e.g. could the same arguments could be made for lspci only
> interface to pci info rather than /proc/bus/pci? The following
> references are made to /proc/bus/pci on my system:
lspci relies on /proc/bus/pci - its the only part of the universe that
actually knows how to handle PCI and virtualised PCI devices. Unlike the
older /proc/pci interface it keeps all the complex gunk out of the kernel
Linus Torvalds
On Tue, 7 May 2002, Padraig Brady wrote:
>
> All the info I've ever needed is /proc/ide/hdx/capacity
> which I could get from /proc/partitions with more a bit
> more effort, so I vote for removing /proc/ide.
Note that one thing that we might do is to leave the remnants of /proc/ide
but _without_ the very verbose per-chipset reporting.
At least to me it looks like it's all the chipset reporting that causes
the huge kernel bloat, and it shouldn't be impossible to reinstate a
minimal /proc/ide without those parts - while still keeping most of the
backwards compatibility.
However, since I really don't much like the idea of having special
"ide-only" /proc files, I personally think any information people actually
used should be either in truly generic files (/proc/partitions as an
example), _or_ they should be in the generic device tree (talk to Pat
Mochel about that).
So my personal reaction to removal of /proc/ide is: "good riddance, but if
it turns out that we seriously need it for backwards compatibility, we can
add back a skeleton without the bloat".
(Side note: I'm afraid that don't think backwards compatibility weighs
very heavily on an embedded setup - I'm more thinking about things like "a
regular RedHat/SuSE/Debian/whatever install won't work any more".)
As to existing binaries (your list is interesting), I don't see what they
are doing about ide-specific stuff, since I sure hope those binaries are
happy with a SCSI-only system.
> For e.g. could the same arguments could be made for lspci only
> interface to pci info rather than /proc/bus/pci? The following
> references are made to /proc/bus/pci on my system:
I personally do like ASCII /proc files, as long as they don't add
maintainability problems etc.
Linus