From: Greg KH <greg@kroah.com>
To: "McMullan, Jason" <jason.mcmullan@timesys.com>
Cc: akpm@zip.com.au, Linux Kernel <linux-kernel@vger.kernel.org>,
ecashin@coraid.com, PPC_LINUX <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
Date: Mon, 16 May 2005 09:20:11 -0700 [thread overview]
Message-ID: <20050516162011.GA8716@kroah.com> (raw)
In-Reply-To: <1116249602.9050.105.camel@jmcmullan.timesys>
On Mon, May 16, 2005 at 09:14:02AM -0400, McMullan, Jason wrote:
> [First off: Andrew, I'm sorry I didn't make it more clear that the AOE
> root patch was just for review, not for submission. Please remove it
> from -mm]
>
>
> On Sat, 2005-05-14 at 00:28 -0700, Greg KH wrote:
> > I'm guessing you are only testing this out on devfs?
>
> Yes. udev takes 5 minutes to complete on my 8mb, 100Mhz board.
Ouch, that's not good at all. Care to take this info to the
linux-hotplug-devel mailing list and we can work on fixing this for you?
(first a few things to try, use 'udevsend' and build udev using klibc.
Also do not have any rules that call out to shell scripts, as you are
using devfs I don't see that you need any special rules at all
probably.)
> > Why not fix this up properly, and allow root devices on _any_ type of
> > block device that is not immediately present at "try to mount time"? The
> > USB and firewire users of the world will love you...
>
> Sure. No problem. Where is this patch you speak of?
It can be based on your patch :)
Anyway, it's floating around in the lkml archives, sorry, don't have a
direct link.
> > Also, please CC the aoe maintainer, that's documented in
> > Documentation/SubmittingPatches :)
>
> I did to support@coraid.com, in a separate message.
That's not the email address listed in MAINTAINERS, is it?
> > > +config ATA_OVER_ETH_ROOT_SHELF
> > > + int "Shelf ID"
> > > + depends on ATA_OVER_ETH_ROOT
> >
> > Ick. Why not use a boot parameter if you really want to use something
> > so icky (hint, we should rely on the name or major/minor, not something
> > else like this.)
>
> Because kernel major/minor change dynamically based upon the number of
> AOE blades on your LAN. As setting them in __setup() - sure, no problem,
> this patch was just a 15 minute hack job.
>
>
> > You do know devfs is going away in 2 months, right?
>
> Yes, much to my disappointment. udevd is so frick'n bloaty.
with klibc? Again, take it to linux-hotplug-devel, if we don't get
reports about problems, we assume that everyone is happy with it. I
haven't seen you asking about this there.
> > Should be in a separate patch, to fix up devfs issues in the driver,
> > right? This goes for the other devfs calls in this patch. That is if
> > you don't mind me removing them in 2 months :)
>
> Yeah, I know, I was just being lazy and using the uber-fast devfs.
It's just a mirrage, it's not really that fast :)
> > If so, I suggest one of the two solutions:
> > - do like the rest of the world does for usb and firewire and
> > other types of slow boot devices and use an initrd/initramfs
> > that mounts the root partition after it is properly found.
> > Distros do this all the time, so there are lots of examples to
> > pull from if you want to do this for yours.
>
> I only have 8Mb of RAM. No room for initrd.
Even with ash built with klibc and/or busybox?
> > - fix up the patch that is floating around that allows the
> > kernel to pause and wait and not oops out if the root
> > partition is not found. That way all users of all kinds of
> > slow devices can benefit, and driver specific hacks like this
> > are not needed.
>
> Again, this happy patch you speak of... Where can I find this wonder?
lkml archives. Or base it on your work you have already started to do
:)
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: "McMullan, Jason" <jason.mcmullan@timesys.com>
Cc: akpm@zip.com.au, ecashin@coraid.com,
Linux Kernel <linux-kernel@vger.kernel.org>,
PPC_LINUX <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
Date: Mon, 16 May 2005 09:20:11 -0700 [thread overview]
Message-ID: <20050516162011.GA8716@kroah.com> (raw)
In-Reply-To: <1116249602.9050.105.camel@jmcmullan.timesys>
On Mon, May 16, 2005 at 09:14:02AM -0400, McMullan, Jason wrote:
> [First off: Andrew, I'm sorry I didn't make it more clear that the AOE
> root patch was just for review, not for submission. Please remove it
> from -mm]
>
>
> On Sat, 2005-05-14 at 00:28 -0700, Greg KH wrote:
> > I'm guessing you are only testing this out on devfs?
>
> Yes. udev takes 5 minutes to complete on my 8mb, 100Mhz board.
Ouch, that's not good at all. Care to take this info to the
linux-hotplug-devel mailing list and we can work on fixing this for you?
(first a few things to try, use 'udevsend' and build udev using klibc.
Also do not have any rules that call out to shell scripts, as you are
using devfs I don't see that you need any special rules at all
probably.)
> > Why not fix this up properly, and allow root devices on _any_ type of
> > block device that is not immediately present at "try to mount time"? The
> > USB and firewire users of the world will love you...
>
> Sure. No problem. Where is this patch you speak of?
It can be based on your patch :)
Anyway, it's floating around in the lkml archives, sorry, don't have a
direct link.
> > Also, please CC the aoe maintainer, that's documented in
> > Documentation/SubmittingPatches :)
>
> I did to support@coraid.com, in a separate message.
That's not the email address listed in MAINTAINERS, is it?
> > > +config ATA_OVER_ETH_ROOT_SHELF
> > > + int "Shelf ID"
> > > + depends on ATA_OVER_ETH_ROOT
> >
> > Ick. Why not use a boot parameter if you really want to use something
> > so icky (hint, we should rely on the name or major/minor, not something
> > else like this.)
>
> Because kernel major/minor change dynamically based upon the number of
> AOE blades on your LAN. As setting them in __setup() - sure, no problem,
> this patch was just a 15 minute hack job.
>
>
> > You do know devfs is going away in 2 months, right?
>
> Yes, much to my disappointment. udevd is so frick'n bloaty.
with klibc? Again, take it to linux-hotplug-devel, if we don't get
reports about problems, we assume that everyone is happy with it. I
haven't seen you asking about this there.
> > Should be in a separate patch, to fix up devfs issues in the driver,
> > right? This goes for the other devfs calls in this patch. That is if
> > you don't mind me removing them in 2 months :)
>
> Yeah, I know, I was just being lazy and using the uber-fast devfs.
It's just a mirrage, it's not really that fast :)
> > If so, I suggest one of the two solutions:
> > - do like the rest of the world does for usb and firewire and
> > other types of slow boot devices and use an initrd/initramfs
> > that mounts the root partition after it is properly found.
> > Distros do this all the time, so there are lots of examples to
> > pull from if you want to do this for yours.
>
> I only have 8Mb of RAM. No room for initrd.
Even with ash built with klibc and/or busybox?
> > - fix up the patch that is floating around that allows the
> > kernel to pause and wait and not oops out if the root
> > partition is not found. That way all users of all kinds of
> > slow devices can benefit, and driver specific hacks like this
> > are not needed.
>
> Again, this happy patch you speak of... Where can I find this wonder?
lkml archives. Or base it on your work you have already started to do
:)
thanks,
greg k-h
next prev parent reply other threads:[~2005-05-16 16:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 19:17 [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2 McMullan, Jason
2005-05-14 7:28 ` Greg KH
2005-05-16 13:20 ` McMullan, Jason
2005-05-16 13:20 ` McMullan, Jason
2005-05-16 16:20 ` Greg KH [this message]
2005-05-16 16:20 ` Greg KH
2005-05-16 17:03 ` Ed L Cashin
2005-05-16 17:03 ` Ed L Cashin
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=20050516162011.GA8716@kroah.com \
--to=greg@kroah.com \
--cc=akpm@zip.com.au \
--cc=ecashin@coraid.com \
--cc=jason.mcmullan@timesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-embedded@ozlabs.org \
/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.