> pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
...
> Dominik is busy. Will probably re-review and send these direct to Linus.
The patch above is the removal of cardmgr support. While I'd love to
see this cruft gone it definitively needs maintainer judgement on whether
they time has come that no one relies on cardmgr anymore.
On Tue, May 01, 2007 at 09:46:23AM +0100, Christoph Hellwig wrote:
> > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
>
> ...
>
> > Dominik is busy. Will probably re-review and send these direct to Linus.
>
> The patch above is the removal of cardmgr support. While I'd love to
> see this cruft gone it definitively needs maintainer judgement on whether
> they time has come that no one relies on cardmgr anymore.
And I still run and use a platform where the GUI issues cardmgr ioctls.
A recent kernel upgrade (from 2.6.9ish to something more recent) broke
the "eject" GUI button applet due to the fscking with the cardmgr ioctls,
and it thinks the wireless card is always plugged in (and therefore the
signal strength meter remains.)
With all the ioctls gone I'll probably loose the signal strength meter.
And no, I don't have the resources (read: code) to fix and rebuild
userspace since I didn't snarf them when the CVS server was alive a
few years back.
That's the problem with API changes - things always break.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hi Christoph,
On Tue, May 01, 2007 at 09:46:23AM +0100, Christoph Hellwig wrote:
> > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
>
> ...
>
> > Dominik is busy. Will probably re-review and send these direct to Linus.
>
> The patch above is the removal of cardmgr support. While I'd love to
> see this cruft gone it definitively needs maintainer judgement on whether
> they time has come that no one relies on cardmgr anymore.
Well, I've not followed evolutions in this area for a long time. Here's
what I get on my notebook :
willy@wtap:~$ uname -r
2.6.20-wt3-wtap
willy@wtap:~$ ps auxw|grep card
root 1216 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
root 1221 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
root 1244 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
root 1251 0.0 0.0 0 0 ? Ss Apr28 0:00 /sbin/cardmgr
What's the new recommended way of using PCMCIA cards when cardmgr is gone ?
Thanks,
Willy
On Tue, 1 May 2007 10:57:10 +0200 Willy Tarreau <[email protected]> wrote:
> Hi Christoph,
>
> On Tue, May 01, 2007 at 09:46:23AM +0100, Christoph Hellwig wrote:
> > > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> >
> > ...
> >
> > > Dominik is busy. Will probably re-review and send these direct to Linus.
> >
> > The patch above is the removal of cardmgr support. While I'd love to
> > see this cruft gone it definitively needs maintainer judgement on whether
> > they time has come that no one relies on cardmgr anymore.
>
> Well, I've not followed evolutions in this area for a long time. Here's
> what I get on my notebook :
>
> willy@wtap:~$ uname -r
> 2.6.20-wt3-wtap
> willy@wtap:~$ ps auxw|grep card
> root 1216 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> root 1221 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> root 1244 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> root 1251 0.0 0.0 0 0 ? Ss Apr28 0:00 /sbin/cardmgr
>
Yes, that seems premature. feature-removal.txt is pretty useless for
getting poeple off old tools. If we're ever to make this migration we'll
need loud and scary printks coming out of the kernel. Probably it'll take
another year or two to get there *once* we've done that.
On Tue, 1 May 2007, Christoph Hellwig wrote:
> > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
>
> ...
>
> > Dominik is busy. Will probably re-review and send these direct to Linus.
>
> The patch above is the removal of cardmgr support. While I'd love
> to see this cruft gone it definitively needs maintainer judgement on
> whether they time has come that no one relies on cardmgr anymore.
since i was the one who submitted the original patch to remove that
stuff, let me make an observation.
when i submitted a patch to remove, for instance, the traffic shaper
since it's clearly obsolete, i was told -- in no uncertain terms --
that that couldn't be done since there had been no warning about its
impending removal.
fair enough, i can accept that.
on the other hand, the features removal file contains the following:
...
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
...
in other words, the PCMCIA ioctl feature *has* been listed as obsolete
for quite some time, and is already a *year and a half* overdue for
removal.
in short, it's annoying to take the position that stuff can't be
deleted without warning, then turn around and be reluctant to remove
stuff for which *more than ample warning* has already been given.
doing that just makes a joke of the features removal file, and makes
you wonder what its purpose is in the first place.
a little consistency would be nice here, don't you think?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Tue, May 01, 2007 at 05:16:13AM -0400, Robert P. J. Day wrote:
> On Tue, 1 May 2007, Christoph Hellwig wrote:
>
> > > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> >
> > ...
> >
> > > Dominik is busy. Will probably re-review and send these direct to Linus.
> >
> > The patch above is the removal of cardmgr support. While I'd love
> > to see this cruft gone it definitively needs maintainer judgement on
> > whether they time has come that no one relies on cardmgr anymore.
>
> since i was the one who submitted the original patch to remove that
> stuff, let me make an observation.
>
> when i submitted a patch to remove, for instance, the traffic shaper
> since it's clearly obsolete, i was told -- in no uncertain terms --
> that that couldn't be done since there had been no warning about its
> impending removal.
>
> fair enough, i can accept that.
>
> on the other hand, the features removal file contains the following:
>
> ...
> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
> When: November 2005
> ...
>
> in other words, the PCMCIA ioctl feature *has* been listed as obsolete
> for quite some time, and is already a *year and a half* overdue for
> removal.
>
> in short, it's annoying to take the position that stuff can't be
> deleted without warning, then turn around and be reluctant to remove
> stuff for which *more than ample warning* has already been given.
> doing that just makes a joke of the features removal file, and makes
> you wonder what its purpose is in the first place.
>
> a little consistency would be nice here, don't you think?
No, it just shows how useless this file is. What is needed is a big
warning during usage, not a file that nobody reads. Facts are :
- 90% of people here do not even know that this file exists
- 80% of the people who know about it do not consult it on a regular basis
- 80% of those who consult it on a regular basis are not concerned
- 75% of statistics are invented
=> only 20% of 20% of 10% of those who read LKML know that one feature
they are concerned about will soon be removed = 0.4% of LKML readers.
If you put a warning in kernel messages (as I've seen for a long time
about tcpdump using obsolete AF_PACKET), close to 100% of the users
of the obsolete code who are likely to change their kernels will notice
it.
I'm sorry for your patch which may get delayed a lot. You would spend
fewer time stuffing warnings in areas affected by scheduled removal.
BTW, I'm not even against the end of cardmgr support, it's just that
I don't know what the alternative is, and I suspect that many users
do not either. A big warning would have brought them to google who
would have provided them with suggestions for alternatives.
Willy
On May 1 2007 05:16, Robert P. J. Day wrote:
>
>on the other hand, the features removal file contains the following:
>
>...
>What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
>When: November 2005
>...
>
>in other words, the PCMCIA ioctl feature *has* been listed as obsolete
>for quite some time, and is already a *year and a half* overdue for
>removal.
>
>in short, it's annoying to take the position that stuff can't be
>deleted without warning, then turn around and be reluctant to remove
>stuff for which *more than ample warning* has already been given.
>doing that just makes a joke of the features removal file, and makes
>you wonder what its purpose is in the first place.
>
>a little consistency would be nice here, don't you think?
I think this could raise their attention...
init/Makefile
obj-y += obsolete.o
init/obsolete.c:
static __init int obsolete_init(void)
{
printk("\e[1;31m""
The following stuff is gonna get removed \e[5;37m SOON: \e[0m
- cardmgr
- foobar
- bweebol
");
schedule_timeout(3 * HZ);
return;
}
static __exit void obsolete_exit(void) {}
Jan
--
On Tue, 1 May 2007, Willy Tarreau wrote:
> On Tue, May 01, 2007 at 05:16:13AM -0400, Robert P. J. Day wrote:
... snip ...
> > in other words, the PCMCIA ioctl feature *has* been listed as
> > obsolete for quite some time, and is already a *year and a half*
> > overdue for removal.
> >
> > in short, it's annoying to take the position that stuff can't be
> > deleted without warning, then turn around and be reluctant to remove
> > stuff for which *more than ample warning* has already been given.
> > doing that just makes a joke of the features removal file, and makes
> > you wonder what its purpose is in the first place.
> >
> > a little consistency would be nice here, don't you think?
>
> No, it just shows how useless this file is.
agreed. it's mildly entertaining to have watched this raging
discussion over the last few days regarding bugs and emails and
bugzilla and adrian's regressions, while the one feature that's meant
to track aging and removable kernel features is essentially valueless,
and no one seems to care.
> What is needed is a big warning during usage, not a file that nobody
> reads.
agreed there as well. but short of that, it would still be nice if
people took a minute, perused the feature removal file, and at least
brought it up-to-date. if it's going to have any value, then:
1) all proposed removal dates should be reviewed to make sure they're
still meaningful,
2) stuff that's overdue for removal should be either removed, or have
its expiry date brought forward, and
3) stuff in the kernel tree that is understood to be obsolete or
nearly so should have an entry added to that file, so that the clock
can at least *start* ticking for that stuff, and you can at least say
you *tried* to warn current users.
as a start, i posted last month the results of running the simple
command:
$ grep -iw obsolete $(find . -name Kconfig\*)
and some of what was printed is clearly misleading. (don't worry,
tilman -- we're not going to reopen that whole isdn4linux thing. :-)
i mean, what of the following is actually obsolete:
* traffic policing
* IP6 Userspace queueing via NETLINK
* IP Userspace queueing via NETLINK
* ebt: ulog support
* Traffic Shaper
and so on (and there's that legacy PM thing as well).
> I'm sorry for your patch which may get delayed a lot.
obviously, leaving stuff like that in the kernel doesn't actually
*hurt* anything but, yeah, it's a tad annoying to invest a few minutes
to do some janitor work based on what should be killable, submit the
patch, then have people freak out about how that is still an essential
feature.
bottom line: if you want janitor folks to help out with cleanup, make
sure they know what can legitimately be cleaned, and stop wasting
peoples' time.
rday
p.s. now if there were only a way to, say, tag various kernel
features as "obsolete" or "deprecated" ... :-)
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Willy Tarreau wrote:
> On Tue, May 01, 2007 at 05:16:13AM -0400, Robert P. J. Day wrote:
>
>> On Tue, 1 May 2007, Christoph Hellwig wrote:
>>
>>
>>>> pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
>>>>
>>> ...
>>>
>>>
>>>> Dominik is busy. Will probably re-review and send these direct to Linus.
>>>>
>>> The patch above is the removal of cardmgr support. While I'd love
>>> to see this cruft gone it definitively needs maintainer judgement on
>>> whether they time has come that no one relies on cardmgr anymore.
>>>
>> since i was the one who submitted the original patch to remove that
>> stuff, let me make an observation.
>>
>> when i submitted a patch to remove, for instance, the traffic shaper
>> since it's clearly obsolete, i was told -- in no uncertain terms --
>> that that couldn't be done since there had been no warning about its
>> impending removal.
>>
>> fair enough, i can accept that.
>>
>> on the other hand, the features removal file contains the following:
>>
>> ...
>> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
>> When: November 2005
>> ...
>>
>> in other words, the PCMCIA ioctl feature *has* been listed as obsolete
>> for quite some time, and is already a *year and a half* overdue for
>> removal.
>>
>> in short, it's annoying to take the position that stuff can't be
>> deleted without warning, then turn around and be reluctant to remove
>> stuff for which *more than ample warning* has already been given.
>> doing that just makes a joke of the features removal file, and makes
>> you wonder what its purpose is in the first place.
>>
>> a little consistency would be nice here, don't you think?
>>
>
> No, it just shows how useless this file is. What is needed is a big
> warning during usage, not a file that nobody reads. Facts are :
>
> - 90% of people here do not even know that this file exists
> - 80% of the people who know about it do not consult it on a regular basis
> - 80% of those who consult it on a regular basis are not concerned
> - 75% of statistics are invented
>
> => only 20% of 20% of 10% of those who read LKML know that one feature
> they are concerned about will soon be removed = 0.4% of LKML readers.
>
> If you put a warning in kernel messages (as I've seen for a long time
> about tcpdump using obsolete AF_PACKET), close to 100% of the users
> of the obsolete code who are likely to change their kernels will notice
> it.
>
>
Hmm ? There is already a fat warning in dmesg for a long time now.
snip
...
pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover.
pcmcia: This interface will soon be removed from the kernel; please
expect breakage unless you upgrade to new tools.
pcmcia: see
http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
...
> I'm sorry for your patch which may get delayed a lot. You would spend
> fewer time stuffing warnings in areas affected by scheduled removal.
>
> BTW, I'm not even against the end of cardmgr support, it's just that
> I don't know what the alternative is, and I suspect that many users
> do not either. A big warning would have brought them to google who
> would have provided them with suggestions for alternatives.
>
> Willy
>
>
>
Regards,
Gabriel
On Tue, May 01, 2007 at 12:26:48PM +0200, Gabriel C wrote:
> Willy Tarreau wrote:
> >On Tue, May 01, 2007 at 05:16:13AM -0400, Robert P. J. Day wrote:
> >
> >>On Tue, 1 May 2007, Christoph Hellwig wrote:
> >>
> >>
> >>>> pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> >>>>
> >>>...
> >>>
> >>>
> >>>>Dominik is busy. Will probably re-review and send these direct to
> >>>>Linus.
> >>>>
> >>>The patch above is the removal of cardmgr support. While I'd love
> >>>to see this cruft gone it definitively needs maintainer judgement on
> >>>whether they time has come that no one relies on cardmgr anymore.
> >>>
> >>since i was the one who submitted the original patch to remove that
> >>stuff, let me make an observation.
> >>
> >>when i submitted a patch to remove, for instance, the traffic shaper
> >>since it's clearly obsolete, i was told -- in no uncertain terms --
> >>that that couldn't be done since there had been no warning about its
> >>impending removal.
> >>
> >>fair enough, i can accept that.
> >>
> >>on the other hand, the features removal file contains the following:
> >>
> >>...
> >>What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
> >>When: November 2005
> >>...
> >>
> >>in other words, the PCMCIA ioctl feature *has* been listed as obsolete
> >>for quite some time, and is already a *year and a half* overdue for
> >>removal.
> >>
> >>in short, it's annoying to take the position that stuff can't be
> >>deleted without warning, then turn around and be reluctant to remove
> >>stuff for which *more than ample warning* has already been given.
> >>doing that just makes a joke of the features removal file, and makes
> >>you wonder what its purpose is in the first place.
> >>
> >>a little consistency would be nice here, don't you think?
> >>
> >
> >No, it just shows how useless this file is. What is needed is a big
> >warning during usage, not a file that nobody reads. Facts are :
> >
> > - 90% of people here do not even know that this file exists
> > - 80% of the people who know about it do not consult it on a regular
> > basis
> > - 80% of those who consult it on a regular basis are not concerned
> > - 75% of statistics are invented
> >
> >=> only 20% of 20% of 10% of those who read LKML know that one feature
> > they are concerned about will soon be removed = 0.4% of LKML readers.
> >
> >If you put a warning in kernel messages (as I've seen for a long time
> >about tcpdump using obsolete AF_PACKET), close to 100% of the users
> >of the obsolete code who are likely to change their kernels will notice
> >it.
> >
> >
>
> Hmm ? There is already a fat warning in dmesg for a long time now.
>
>
> snip
>
> ...
>
> pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover.
> pcmcia: This interface will soon be removed from the kernel; please
> expect breakage unless you upgrade to new tools.
> pcmcia: see
> http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
>
> ...
Oh you're terribly right ! I have grepped my logs and found it lying
there too in the middle of the memory probe messages and the IO probe
ones. I never noticed it. I know it's my fault, but I think that
"fat warning" is not really what could characterize it though, because
of the context verbose around it :
pcmcia: parent PCI bridge Memory window: 0x90000000 - 0x903fffff
pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x3dffffff
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x90000000-0x903fffff: excluding 0x90000000-0x9003ffff 0x90080000-0x900bffff 0x90100000-0x9013ffff 0x90180000-0x901bffff 0x90200000-0x9023ffff 0x90280000-0x902bffff 0x90300000-0x9033ffff 0x90380000-0x903bffff
pcmcia: registering new device pcmcia0.0
pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr.
pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools.
pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
cs: IO port probe 0xc00-0xcff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0x800-0x80f: clean.
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x100-0x3af: excluding 0x140-0x14f 0x378-0x37f
cs: IO port probe 0xa00-0xaff: clean.
Now I have the URL for the details ;-)
BTW, I thing we should standardize on some formating to display messages
about deprecated/obsolete code. Maybe something like this would be more
noticeable :
cs: memory probe 0x90000000-0x903fffff: excluding 0x90000000-0x9003ffff 0x90080000-0x900bffff 0x90100000-0x9013ffff 0x90180000-0x901bffff 0x90200000-0x9023ffff 0x90280000-0x902bffff 0x90300000-0x9033ffff 0x90380000-0x903bffff
pcmcia: registering new device pcmcia0.0
WARNING !!! Detected DEPRECATED PCMCIA ioctl usage from process: cardmgr.
WARNING !!! This process may stop working past November 2005.
WARNING !!! see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
cs: IO port probe 0xc00-0xcff: clean.
Regards,
Willy
On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
>
> On May 1 2007 05:16, Robert P. J. Day wrote:
> >
> >on the other hand, the features removal file contains the following:
> >
> >...
> >What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
> >When: November 2005
> >...
> >
> >in other words, the PCMCIA ioctl feature *has* been listed as obsolete
> >for quite some time, and is already a *year and a half* overdue for
> >removal.
> >
> >in short, it's annoying to take the position that stuff can't be
> >deleted without warning, then turn around and be reluctant to remove
> >stuff for which *more than ample warning* has already been given.
> >doing that just makes a joke of the features removal file, and makes
> >you wonder what its purpose is in the first place.
> >
> >a little consistency would be nice here, don't you think?
>
> I think this could raise their attention...
>
> init/Makefile
> obj-y += obsolete.o
>
> init/obsolete.c:
> static __init int obsolete_init(void)
> {
> printk("\e[1;31m""
>
> The following stuff is gonna get removed \e[5;37m SOON: \e[0m
> - cardmgr
> - foobar
> - bweebol
>
> ");
> schedule_timeout(3 * HZ);
> return;
> }
>
> static __exit void obsolete_exit(void) {}
There's something I like here : the fact that all features are centralized
and not hidden in the noise. Clearly we need some standard inside the kernel
to manage obsolete code as well as we currently do by hand.
Willy
Willy Tarreau wrote:
> On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
>> On May 1 2007 05:16, Robert P. J. Day wrote:
>>> on the other hand, the features removal file contains the following:
>>>
>>> ...
>>> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
>>> When: November 2005
>>> ...
>>>
>>> in other words, the PCMCIA ioctl feature *has* been listed as obsolete
>>> for quite some time, and is already a *year and a half* overdue for
>>> removal.
>>>
>>> in short, it's annoying to take the position that stuff can't be
>>> deleted without warning, then turn around and be reluctant to remove
>>> stuff for which *more than ample warning* has already been given.
>>> doing that just makes a joke of the features removal file, and makes
>>> you wonder what its purpose is in the first place.
>>>
>>> a little consistency would be nice here, don't you think?
>> I think this could raise their attention...
>>
>> init/Makefile
>> obj-y += obsolete.o
>>
>> init/obsolete.c:
>> static __init int obsolete_init(void)
>> {
>> printk("\e[1;31m""
>>
>> The following stuff is gonna get removed \e[5;37m SOON: \e[0m
>> - cardmgr
>> - foobar
>> - bweebol
>>
>> ");
>> schedule_timeout(3 * HZ);
>> return;
>> }
>>
>> static __exit void obsolete_exit(void) {}
>
> There's something I like here : the fact that all features are centralized
> and not hidden in the noise. Clearly we need some standard inside the kernel
> to manage obsolete code as well as we currently do by hand.
>
> Willy
What about something like the tainted flag which status can be displayed
easily? And even better when a list of the used obsolete features can
be displayed as well on request? This way you don't need to search the
logs. A standardized obsolete function like the one above could do all
the job.
Just my 2 cents.
--
Konstantin M?nning
Willy Tarreau wrote:
> On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
>> On May 1 2007 05:16, Robert P. J. Day wrote:
>>> on the other hand, the features removal file contains the following:
>>>
>>> ...
>>> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
>>> When: November 2005
>>> ...
>>>
>>> in other words, the PCMCIA ioctl feature *has* been listed as obsolete
>>> for quite some time, and is already a *year and a half* overdue for
>>> removal.
>>>
>>> in short, it's annoying to take the position that stuff can't be
>>> deleted without warning, then turn around and be reluctant to remove
>>> stuff for which *more than ample warning* has already been given.
>>> doing that just makes a joke of the features removal file, and makes
>>> you wonder what its purpose is in the first place.
>>>
>>> a little consistency would be nice here, don't you think?
>> I think this could raise their attention...
>>
>> init/Makefile
>> obj-y += obsolete.o
>>
>> init/obsolete.c:
>> static __init int obsolete_init(void)
>> {
>> printk("\e[1;31m""
>>
>> The following stuff is gonna get removed \e[5;37m SOON: \e[0m
>> - cardmgr
>> - foobar
>> - bweebol
>>
>> ");
>> schedule_timeout(3 * HZ);
>> return;
>> }
>>
>> static __exit void obsolete_exit(void) {}
>
> There's something I like here : the fact that all features are centralized
> and not hidden in the noise. Clearly we need some standard inside the kernel
> to manage obsolete code as well as we currently do by hand.
>
> Willy
The difference between this function and the PCAP/TCPDUMP warning is
that the warning only showed up when the obsolete functionality was
actually used.
Maybe a mechanism to automatically increase the severity of reporting as
the removal date approaches would be an idea? i.e. for each new kernel
that you build leading up the the removal date, a severity is calculated
based on the time until official removal, and then, depending on the
severity, the message can be logged in various ways.
Rogan
On Tue, May 01, 2007 at 02:08:20AM -0700, Andrew Morton wrote:
> On Tue, 1 May 2007 10:57:10 +0200 Willy Tarreau <[email protected]> wrote:
>
> > Hi Christoph,
> >
> > On Tue, May 01, 2007 at 09:46:23AM +0100, Christoph Hellwig wrote:
> > > > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> > >
> > > ...
> > >
> > > > Dominik is busy. Will probably re-review and send these direct to Linus.
> > >
> > > The patch above is the removal of cardmgr support. While I'd love to
> > > see this cruft gone it definitively needs maintainer judgement on whether
> > > they time has come that no one relies on cardmgr anymore.
> >
> > Well, I've not followed evolutions in this area for a long time. Here's
> > what I get on my notebook :
> >
> > willy@wtap:~$ uname -r
> > 2.6.20-wt3-wtap
> > willy@wtap:~$ ps auxw|grep card
> > root 1216 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> > root 1221 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> > root 1244 0.0 0.0 0 0 ? S< Apr28 0:00 [pccardd]
> > root 1251 0.0 0.0 0 0 ? Ss Apr28 0:00 /sbin/cardmgr
> >
>
> Yes, that seems premature. feature-removal.txt is pretty useless for
> getting poeple off old tools. If we're ever to make this migration we'll
> need loud and scary printks coming out of the kernel. Probably it'll take
> another year or two to get there *once* we've done that.
You already said the same two years ago, and you forwarded a patch
implementing exactly this nearly two years ago:
commit c352ec8ab87b065cd2edda171811f49ac7d0d5cd
Author: Dominik Brodowski <[email protected]>
Date: Tue Sep 13 01:25:03 2005 -0700
[PATCH] pcmcia: warn on IOCTL usage
More visible user information of scheduled feature removal.
Signed-off-by: Dominik Brodowski <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
diff --git a/drivers/pcmcia/pcmcia_ioctl.c b/drivers/pcmcia/pcmcia_ioctl.c
index 39ba640..80969f7 100644
--- a/drivers/pcmcia/pcmcia_ioctl.c
+++ b/drivers/pcmcia/pcmcia_ioctl.c
@@ -376,6 +376,7 @@ static int ds_open(struct inode *inode, struct file *file)
socket_t i = iminor(inode);
struct pcmcia_socket *s;
user_info_t *user;
+ static int warning_printed = 0;
ds_dbg(0, "ds_open(socket %d)\n", i);
@@ -407,6 +408,17 @@ static int ds_open(struct inode *inode, struct file *file)
s->user = user;
file->private_data = user;
+ if (!warning_printed) {
+ printk(KERN_INFO "pcmcia: Detected deprecated PCMCIA ioctl "
+ "usage.\n");
+ printk(KERN_INFO "pcmcia: This interface will soon be removed from "
+ "the kernel; please expect breakage unless you upgrade "
+ "to new tools.\n");
+ printk(KERN_INFO "pcmcia: see http://www.kernel.org/pub/linux/"
+ "utils/kernel/pcmcia/pcmcia.html for details.\n");
+ warning_printed = 1;
+ }
+
if (s->pcmcia_state.present)
queue_event(user, CS_EVENT_CARD_INSERTION);
return 0;
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
> init/obsolete.c:
> static __init int obsolete_init(void)
> {
> printk("\e[1;31m""
>
> The following stuff is gonna get removed \e[5;37m SOON: \e[0m
> - cardmgr
> - foobar
> - bweebol
>
> ");
> schedule_timeout(3 * HZ);
> return;
> }
The kernel console isn't VT102 compatible. It doesn't understand any
escape codes, at all. Neither does sysklogd. So the above will just
end up as rubbish on your console.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On May 1 2007 20:10, Russell King wrote:
>On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
>> init/obsolete.c:
>> static __init int obsolete_init(void)
>> {
>> printk("\e[1;31m""
>>
>> The following stuff is gonna get removed \e[5;37m SOON: \e[0m
>> - cardmgr
>> - foobar
>> - bweebol
>>
>> ");
>> schedule_timeout(3 * HZ);
>> return;
>> }
>
>The kernel console isn't VT102 compatible. It doesn't understand any
>escape codes, at all. Neither does sysklogd. So the above will just
>end up as rubbish on your console.
It will (should) at least show up as nicely as in the C source code.
With escape codes, but largely readable.
If someone knows how to directly spew it to tty0 (the current active console -
most likely tty1), the better.
Anyway, I just wanted to point out how to really highlight it for the user to
see. Although then there would be the distros who obscure it with funky
bootsplash screens. But hopefully, their users would not need to care too much
for old stuff (gets updated through the distro's update mechanism)
Jan
--
Hi!
> > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
>
> ...
>
> > Dominik is busy. Will probably re-review and send these direct to Linus.
>
> The patch above is the removal of cardmgr support. While I'd love to
> see this cruft gone it definitively needs maintainer judgement on whether
> they time has come that no one relies on cardmgr anymore.
I remember needing cardmgr few months ago on sa-1100 arm system. I'm
not sure this is obsolete-enough to kill.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 9 May 2007, Pavel Machek wrote:
> Hi!
>
> > > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> >
> > ...
> >
> > > Dominik is busy. Will probably re-review and send these direct to Linus.
> >
> > The patch above is the removal of cardmgr support. While I'd love
> > to see this cruft gone it definitively needs maintainer judgement
> > on whether they time has come that no one relies on cardmgr
> > anymore.
>
> I remember needing cardmgr few months ago on sa-1100 arm system. I'm
> not sure this is obsolete-enough to kill.
in that case, someone really should update
feature-removal-schedule.txt, which currently reads:
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
...
rday
--
========================================================================
Robert P. J. Day Linux Consulting, Training and Annoying Kernel
Pedantry Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Wed, May 09, 2007 at 12:54:16PM +0000, Pavel Machek wrote:
> Hi!
>
> > > pcmcia-delete-obsolete-pcmcia_ioctl-feature.patch
> >
> > ...
> >
> > > Dominik is busy. Will probably re-review and send these direct to Linus.
> >
> > The patch above is the removal of cardmgr support. While I'd love to
> > see this cruft gone it definitively needs maintainer judgement on whether
> > they time has come that no one relies on cardmgr anymore.
>
> I remember needing cardmgr few months ago on sa-1100 arm system. I'm
> not sure this is obsolete-enough to kill.
Why didn't pcmciautils work?
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 2007-05-09 at 15:03 +0200, Adrian Bunk wrote:
> On Wed, May 09, 2007 at 12:54:16PM +0000, Pavel Machek wrote:
> relies on cardmgr anymore.
> >
> > I remember needing cardmgr few months ago on sa-1100 arm system. I'm
> > not sure this is obsolete-enough to kill.
>
> Why didn't pcmciautils work?
I have had a problem until 2.6.20 was out with pcmciautils (it did not
recognise the second function of multi-functions pcmcia cards that
needed a firmware .cis file), and the only way to use it was with
cardmgr, way after Nov 2005 :-).
Now it is solved (modulo that sometime the pcmcia modem is ttyS1,
sometime ttyS2, but that's another history --- and probably my fault).
But I wonder if similar problems are hidden away... what about put the
ioctls under a normally-disabled option and let a kernel out with it?
Romano
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
On Wed, May 09, 2007 at 09:11:52PM +0200, Romano Giannetti wrote:
> On Wed, 2007-05-09 at 15:03 +0200, Adrian Bunk wrote:
> > On Wed, May 09, 2007 at 12:54:16PM +0000, Pavel Machek wrote:
> > relies on cardmgr anymore.
> > >
> > > I remember needing cardmgr few months ago on sa-1100 arm system. I'm
> > > not sure this is obsolete-enough to kill.
> >
> > Why didn't pcmciautils work?
>
> I have had a problem until 2.6.20 was out with pcmciautils (it did not
> recognise the second function of multi-functions pcmcia cards that
> needed a firmware .cis file), and the only way to use it was with
> cardmgr, way after Nov 2005 :-).
>
> Now it is solved (modulo that sometime the pcmcia modem is ttyS1,
> sometime ttyS2, but that's another history --- and probably my fault).
> But I wonder if similar problems are hidden away... what about put the
> ioctls under a normally-disabled option and let a kernel out with it?
It already prints a runtime warning to the user since 2005.
And people won't notice a changed default when using "make oldconfig".
Are there any known known regressions left?
Otherwise, the best way for getting problem reports for pcmciautils is
to remove the ioctl (that's an experience from similar cases in other
parts of the kernel)...
> Romano
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed