[cgl_discussion] Feedback on Requirements doc 20020417

[Khalid Aziz]

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
	watchdog timer".

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
	remove this.

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
	requirement.

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
	this.


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

====================================================================
Khalid Aziz                              Linux Systems Operation R&D
(970)898-9214                                        Hewlett-Packard
khalid at fc.hp.com                                    Fort Collins, CO