On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote:
> boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar
> with (arch/um), that is usable from the beginning of start_kernel. I don't
> know about the other arches.
setup_arch does the necessary initialization
[EMAIL PROTECTED] said:
> I was unsure if it was okay to be using kmalloc during early stages of
> init/main.c so I decided to follow the example allready set and just
> use a static array - can anyone advise on being able to do this
> dynamically?
kmalloc is usable after mem_init(), I think.
[Tracy Camp]
> I was unsure if it was okay to be using kmalloc during early stages
> of init/main.c so I decided to follow the example allready set and
> just use a static array - can anyone advise on being able to do this
> dynamically?
Have a static 'char *' somewhere. In the "root="
> Hmmm, I don't like your array thing (also in v.I of the patch),
> limiting us to possible root devices, where n==8. A better
> approach might be to iterate over the root= arguments when mounting. I
> know why you used the array -- easier to code.
I was unsure if it was okay to be using
[I wrote]
> Your patch makes it impossible, in this situation, to override the
> default root device from the syslinux command line. A kludge to make
> it work again would be to process the root devices in reverse.
Better would be to reset the list of root devices with every 'root='
statement,
[Tracy Camp]
> A much cleaner patch prompted after right proper chastisement on the
> sloppy patch I sent a few days back. This one is against 2.4-pre11
Hmmm, I don't like your array thing (also in v.I of the patch),
limiting us to possible root devices, where n==8. A better
approach might
On Fri, 1 Dec 2000, T. Camp wrote:
> Hmm didn't know that, from the user-land portable C perspective I'm in the
> habit of zero'ing everything. - thanks.
Yes, sorry, I should have explained a bit more, perhaps. The point is that
when you have an unitialized variable like this:
int x;
the C
On Fri, Dec 01, 2000 at 09:05:23AM -0800, T. Camp wrote:
> Hmm didn't know that, from the user-land portable C perspective I'm in the
> habit of zero'ing everything. - thanks.
It's a requirement of the ISO C standard that all global/static (not
local) variables are initialized to 0 is not
> indeed, much cleaner. But still not perfect.
>
> > + int root_device_index = 0;
>
> this initialisation is not needed. Just make it 'int root_device_index;'
> The kernel will do the right thing for you on boot, trust me.
>
> > +int number_root_devs = 0;
>
> this is not needed either.
Hmm
Hello,
On Fri, 1 Dec 2000, T. Camp wrote:
> A much cleaner patch prompted after right proper chastisement on the
indeed, much cleaner. But still not perfect.
> + int root_device_index = 0;
this initialisation is not needed. Just make it 'int root_device_index;'
The kernel will do the
A much cleaner patch prompted after right proper chastisement on the
sloppy patch I sent a few days back. This one is against 2.4-pre11 but so
far as I can tell should be good to go against any of the 2.4 series so
far.
I have not implemented a regex-like syntax as was suggested because 1) you
A much cleaner patch prompted after right proper chastisement on the
sloppy patch I sent a few days back. This one is against 2.4-pre11 but so
far as I can tell should be good to go against any of the 2.4 series so
far.
I have not implemented a regex-like syntax as was suggested because 1) you
Hello,
On Fri, 1 Dec 2000, T. Camp wrote:
A much cleaner patch prompted after right proper chastisement on the
indeed, much cleaner. But still not perfect.
+ int root_device_index = 0;
this initialisation is not needed. Just make it 'int root_device_index;'
The kernel will do the right
indeed, much cleaner. But still not perfect.
+ int root_device_index = 0;
this initialisation is not needed. Just make it 'int root_device_index;'
The kernel will do the right thing for you on boot, trust me.
+int number_root_devs = 0;
this is not needed either.
Hmm didn't know
On Fri, 1 Dec 2000, T. Camp wrote:
Hmm didn't know that, from the user-land portable C perspective I'm in the
habit of zero'ing everything. - thanks.
Yes, sorry, I should have explained a bit more, perhaps. The point is that
when you have an unitialized variable like this:
int x;
the C
On Fri, Dec 01, 2000 at 09:05:23AM -0800, T. Camp wrote:
Hmm didn't know that, from the user-land portable C perspective I'm in the
habit of zero'ing everything. - thanks.
It's a requirement of the ISO C standard that all global/static (not
local) variables are initialized to 0 is not
[Tracy Camp]
A much cleaner patch prompted after right proper chastisement on the
sloppy patch I sent a few days back. This one is against 2.4-pre11
Hmmm, I don't like your array thing (also in v.I of the patch),
limiting us to n possible root devices, where n==8. A better
approach might be
[I wrote]
Your patch makes it impossible, in this situation, to override the
default root device from the syslinux command line. A kludge to make
it work again would be to process the root devices in reverse.
Better would be to reset the list of root devices with every 'root='
statement,
Hmmm, I don't like your array thing (also in v.I of the patch),
limiting us to n possible root devices, where n==8. A better
approach might be to iterate over the root= arguments when mounting. I
know why you used the array -- easier to code.
I was unsure if it was okay to be using kmalloc
[Tracy Camp]
I was unsure if it was okay to be using kmalloc during early stages
of init/main.c so I decided to follow the example allready set and
just use a static array - can anyone advise on being able to do this
dynamically?
Have a static 'char *' somewhere. In the "root=" callback
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote:
boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar
with (arch/um), that is usable from the beginning of start_kernel. I don't
know about the other arches.
setup_arch does the necessary initialization on
21 matches
Mail list logo
