Max wrote:Could be ... I wasn't paying close attention to the details. If so, a good product marketing manager would first upsell the customer to the better product, and then let falling sales guide the removal of the old product. That is, if you can guide most of the users of "isolcpus=" to a better solution, in -their- view, so that they voluntary choose to migrate to the other solution, then you get to deprecate and then remove the old mechanism. To the extent that you can show that the old mechanism is costing us (maintenance, reliability, performance, impeding progress, ...) then you get to accelerate the deprecation period, even to the point of an immediate removal of the old feature, if it's of sufficiently little use and great pain. We do have one problem with letting "falling sales" guide feature removal. Unlike Walmart, where they know what has sold where before the customer has even left the store, we can't easily track usage of kernel features. Occassionally, we can stir the pot and get some feedback, as I've done on this thread, if we have a narrow target audience that we have good reason is especially interested. But that only works occassionally. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --
| Justin C. Sherrill | Re: dragonflybsd.org website link? |
| David Woodhouse | Re: -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Patrick McHardy | [NET_SCHED 01/15]: sch_atm: fix format string warning |
