[cgl_discussion] Feedback on Requirements doc 20020417
khalid at fc.hp.com
Fri Apr 19 15:45:04 PDT 2002
Here is my feedback on the requirements doc:
35.0 Which specific drivers will be hardened and what will govern
the choice for CGLWG?
55.0 This imposes a hardware requirement to include a watchdog timer
on the platform. It should be reworded as "CGL shall support a
55.1 This seems to imply a userspace tool that resets the watchdog
timer. Is that the intent? Confiurable timeout at compile time
or run time? WHat is meant by configurable action upon timeout?
Watchdog timers simply reset the system if there is a timeout.
55.2 What will this interrupt routine do?
56 This is HA app space. We should stay out of this space. Suggest we
70 All of this is very much in application space and this is where
distros try to add value. Suggest we remove this.
80 We need to assert this feature would be provided by CGL only if
SAF mandates such a feature. We are definitely treading over
middleware space here.
82 This is middleware space even if it is covered by SAF. SAF specs
are meant for middleware providers as well. We should not
mandate a standard data checkpointing software and kill the case
for ISVs providing this feature.
90 How can we even control application software live upgrade? Live
upgrade of app is very software specific and we can not
guarantee this can even be done. To top that we can not
guarantee the maximum downtimes quoted once we expand this
requirement to applications. Live upgrade should be
restricted to kernel, libraries (maybe) and Unix utilities.
90.1 We do not control applications. You never know when someone
would design an app that can not be restarted cleanly after an
upgrade without a full reboot. I would suggest dropping this
90.x We need to define what we mean by software -
kernel+libraries+utilities or all this plus applications.
100.3 Do we have any justification for requiring this report? This
adds more work to PoC. So I would like to see if there is a need
for this work.
111 This is easy to state but hard to implement. Have we given any
thought to how could we even implement something like this? The
idea of using Linux kernel itself as a bootloader was discussed
at face-to-face butthat is nowhere near trivial to achieve.
113 Same comments as 111.
120.1 I would restrict it to the preemption enhancements made to 2.5
kernel. pre-emptive kernel can be a wide open thing.
165.1 How will sys admin specify this list of data structures - at
runtime, at compile time?
175.1 What is driving the need for this report?
175.2 Are we saying we will only identify the enhancements or are we
saying we will implement them as well?
200 Are we implying we will modify every printk to conform to event
logging format? If so, didn't we count something like 47000
printk's in the kernel? That is a huge task.
210.2 Typo??? Does not make sense.
231 We will look at it only if we are supporting clusters as well.
335 Do we have any justification for this report? It is more work for
PoC. It would be good to know if there is any justification for
Also further down in the document under the heading "General Kernel
Scheduler Improvements", there are items "Selectable scheduler
framework" and "Install desired scheduler at compile or boot time". The
comments next to it say "Covered by other scheduler requirements" but I
did not see this covered in the requirements. Did I miss something or
did it just get dropped?
Khalid Aziz Linux Systems Operation R&D
khalid at fc.hp.com Fort Collins, CO
More information about the cgl_discussion