All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
Cc: linux-kernel@vger.kernel.org, Pete Zaitcev <zaitcev@redhat.com>
Subject: Re: Patch for kernel.real-root-dev on s390
Date: Sat, 10 Nov 2001 12:58:32 -0500	[thread overview]
Message-ID: <20011110125832.A21437@devserv.devel.redhat.com> (raw)
In-Reply-To: <200111100248.DAA00341@faui11.informatik.uni-erlangen.de>
In-Reply-To: <200111100248.DAA00341@faui11.informatik.uni-erlangen.de>; from weigand@immd1.informatik.uni-erlangen.de on Sat, Nov 10, 2001 at 03:48:33AM +0100

> From: Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
> Date: Sat, 10 Nov 2001 03:48:33 +0100 (MET)
> Cc: linux-kernel@vger.kernel.org

> I agree that this looks broken, but I don't see why it 
> would be s390 specific.  The clobber of adjacent memory
> happens on all architectures, and on all big endian systems
> the value read is incorrect even if adjacent memory happens 
> to be 0.

Probably alignment restrictions do not allow anything interesting
to happen. I know now that ppc people complained about it.

> However, I'm not convinced the patch is a proper fix; it
> will cause the MAJOR and MINOR macros to be applied to a
> variable not of type kdev_t, which happens to work now but will 
> break if the definition of kdev_t is changed to a structure
> or pointer type (as it probably will at some point in the 
> future, if I recall the various discussions correctly).
> 
> What about either
>  - adding support for kdev_t values to procfs
> or

I thought that would be the right thing to do when kdev_t is changed.
Currently, I do not know how to change it. Guy Streeter told me
that someone floated an insanely ugly patch that special-cased
shorts into do_proc_dointvec(), and I did not like that approach
too much. Once the structure of new kdev_t is known, the
do_proc_kdev_t may be defined, but I think it makes no sense
to jump the gun now.

>  - keeping two int variables real_root_major and 
>    real_root_minor ?

Who knows if we are going to have majors and minors at all.
Suppose Gooch and Viro give us a decent devfs, or something.

An alternative may be to redo the initrd interface, for instance
have /proc/real-root-path instead of real-root-dev (and no sysctl),
I did not have time to explore all implications of that way.

-- Pete

  reply	other threads:[~2001-11-10 18:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-10  2:48 Patch for kernel.real-root-dev on s390 Ulrich Weigand
2001-11-10 17:58 ` Pete Zaitcev [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-11-07 22:11 Pete Zaitcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011110125832.A21437@devserv.devel.redhat.com \
    --to=zaitcev@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=weigand@immd1.informatik.uni-erlangen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.