Pawel Jakub Dawidek wrote:
On Tue, Jan 30, 2007 at 04:36:36PM -0500, John Baldwin wrote:
On Monday 29 January 2007 15:19, Pawel Jakub Dawidek wrote:
I fully agree that there should be a clean KPI for this. What you
proposed if fine. Because of lack of such KPI geli has to handle HTT
CPUs which are turned off by default in releases also by abusing
scheduler internals. KPI you proposed would allow me to remove those
hacks. And I'm really all for it.

What you and Scott are missing is that when I implement a GEOM class,
I'm using what is available to do my work. I'm not going to educate
myself how schedulers work, implement nice and clean KPI to use it in
my class. I'm not saying it wouldn't be great to be able to do so, but I
don't have time for everything, unfortunately, and you guys should
understand that very well.
Something you seem to be missing though is that in general it's nice to not just endulge in an endless series of hacks in your specific area of the system. IWBN to at some point devote some time to help fix more general problems that will benefit the system as a whole rather than adding hacks that just benefit yourself and require someone else to clean up when they eventually add the more-architected solution. We are all very busy, but if everyone just did hacks and never put any effort into improving the general infrastructure, we'd have a royal mess.

To improve the infrastructure, one should feel strong about areas he
want to improve. I do infrastructual work in areas, where I think I've a
clue. Asking me to work on schedulers or SMP architecture where I don't
feel competent enough is just unfair, John. The time I need to spend on
educating myself in those areas will be much longer than I can afford.
So my choice is leave broken code and ignore the users, or fix it using
tools available now and fix it better when the infrastructure is ready
or I've time to work on the infrastructure in this area.
If someone competent will provide infrastructural improvements I can
use, I'd love to use it. I try hard not to leave my code behind.

Can we move on now?


You're quite naive if you think that people like John and myself work on infrastructure for any other reason than that it needs to be done. You may not feel that it's your job to do good architecture, but whatever you propose to put into FreeBSD is still subject to peer review. Keep
this in mind.

Scott

_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to