Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 8月, 2008 2 次提交
  3. 02 8月, 2008 1 次提交
  5. 26 7月, 2008 1 次提交
  7. 25 7月, 2008 1 次提交
  9. 22 7月, 2008 1 次提交
  11. 21 7月, 2008 1 次提交
  13. 17 7月, 2008 3 次提交
  15. 16 7月, 2008 1 次提交
  17. 05 7月, 2008 2 次提交
  19. 04 7月, 2008 5 次提交
  21. 03 7月, 2008 6 次提交
  23. 21 6月, 2008 2 次提交
  25. 13 6月, 2008 1 次提交
  27. 06 6月, 2008 1 次提交
  29. 30 5月, 2008 2 次提交
  31. 25 5月, 2008 1 次提交
    • M
      brd: don't show ramdisks in /proc/partitions · 53978d0a
      由 Marcin Krol 提交于 
      In 2.6.25, ramdisk devices show up in /proc/partitions, which is a
behaviour change from the old rd.c.  Add GENHD_FL_SUPPRESS_PARTITION_INFO,
which was present in rd.c.

All kernels prior to 2.6.25 weren't displaying ramdisks in
/proc/partitions.  Since there are many userspace tools using information
from /proc/partitions some of them may now behave incorrectly (I didn't
tested any though).  For example before 2.6.25 /proc/partitions was empty
if no block devices like hard disks and such were detected by kernel.  Now
all 16 ramdisks are always visible there.  Some software may rely on such
information (I mean, on empty /proc/partitions).

There was quite similar situation back in 2004, and ramdisks were excluded
back from displaying.  Thats why I called this a regression (maybe a bit
unfortunate).  See this patch for info:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch

I also think that someone somewhere (long time ago) excluded ramdisks from
/proc/partitions for good reasons.  It is possible that now such new
"feature" is harmless, but I think there are more chances that someone
will say "hey, /proc/partitions has changed, now my software doesn't work"
then "hey where did my new 2.6.25 feature go".  nbd devices are also
excluded, maybe for very same (unknown to me) reasons.
Signed-off-by: NMarcin Krol <hawk@pld-linux.org>
Signed-off-by: NNick Piggin <npiggin@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      53978d0a
  33. 23 5月, 2008 1 次提交
  35. 19 5月, 2008 1 次提交
  37. 07 5月, 2008 1 次提交
  39. 03 5月, 2008 4 次提交
  41. 02 5月, 2008 2 次提交
    • R
      virtio: add virtio disk geometry feature · 48e4043d
      由 Ryan Harper 提交于 
      Rather than faking up some geometry, allow the backend to push the disk
geometry via virtio pci config option.  Keep the old geo code around for
compatibility.
Signed-off-by: NRyan Harper <ryanh@us.ibm.com>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (modified to single struct)
      48e4043d
    • R
      virtio: explicit advertisement of driver features · c45a6816
      由 Rusty Russell 提交于 
      A recent proposed feature addition to the virtio block driver revealed
some flaws in the API: in particular, we assume that feature
negotiation is complete once a driver's probe function returns.

There is nothing in the API to require this, however, and even I
didn't notice when it was violated.

So instead, we require the driver to specify what features it supports
in a table, we can then move the feature negotiation into the virtio
core.  The intersection of device and driver features are presented in
a new 'features' bitmap in the struct virtio_device.

Note that this highlights the difference between Linux unsigned-long
bitmaps where each unsigned long is in native endian, and a
straight-forward little-endian array of bytes.

Drivers can still remove feature bits in their probe routine if they
really have to.

API changes:
- dev->config->feature() no longer gets and acks a feature.
- drivers should advertise their features in the 'feature_table' field
- use virtio_has_feature() for extra sanity when checking feature bits
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c45a6816