Re: m68k using deprecated internal APIs?
On Sat, 27 Oct 2018, Geert Uytterhoeven wrote:
> Hi Arnd,
>
> https://lwn.net/Articles/769468/ wrote:
> > For example, the m68k architecture uses a number of internal APIs
> > that no other architecture needs at this point; removing that
> > architecture would enable removing the APIs as well
>
> and
>
> > Ted Ts'o suggested that an ultimatum could be made: either the m68k
> > architecture stops using the old, deprecated timer API (for example)
> > within one year or it is removed from the kernel.
>
> Which APIs are these exactly?
>
Tree-wide replacement of deprecated API's is one thing.
Gunning for one particular architecture is a different matter.
Of course, if that architecture is known to be fatally flawed (hi spectre)
that's quite okay.
--
> > This kind of approach has worked well in the Debian community
>
> Right, Debian stopped supporting m68k a long time ago ;-)
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
Re: m68k using deprecated internal APIs?
On Sat, 27 Oct 2018, John Paul Adrian Glaubitz wrote: > This stuff is so getting annoying. I don't understand why all of a > sudden there is such a big urge to kick everything out that is old. Is > the Linux kernel supposed to be an x86-only project? > Some maintainers don't like mature code. But it's hard to figure out why it is so. Defect density in old code is never used as a criterion. I guess there are perverse incentives at work in industry which don't exist in the wider community. E.g. workers being paid according to the number of lines of code added/removed/modified. Refactoring legacy code can be automated. But doing so would touch fewer lines of code than wholesale deletion, so the incentive seems to be backwards. > I don't get it. The port is actively maintained and working well, new > drivers are being added. And there is a vibrant community using it. Try > buying a used Amiga on eBay and you know what I mean. > > There is new hardware being developed all the time. Just recently, we > added support for the xsurf100 network card from Individual Computers. > And I expect more drivers to be added in the future. > > Is Linux really only a commercial product now so that everything that is > not maintained by a large company needs to go quick? > That has been my impression also. It's very short sighted, because standard practice in engineering is to re-use proven ideas. Old designs get shipped in new guises, albeit smaller and faster. The alternative to re-use is re-invention, which is not obviously profitable but does generate economic activity. Therefore, re-use may be undesirable according to Keynesianism. Also, bogus patents issued for designs that already have prior art may be compounding the problem but this is all just speculation. -- > Adrian > >
Re: m68k using deprecated internal APIs?
On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven wrote: > > Hi Arnd, > > https://lwn.net/Articles/769468/ wrote: > > For example, the m68k architecture uses a number of internal APIs that no > > other > > architecture needs at this point; removing that architecture would enable > > removing > > the APIs as well > > and > > > Ted Ts'o suggested that an ultimatum could be made: either the m68k > > architecture > > stops using the old, deprecated timer API (for example) within one year or > > it is > > removed from the kernel. > > Which APIs are these exactly? The example I gave was GENERIC_CLOCKEVENTS on m68, which is supported on most but not all machines there. This is also missing on a couple of others (ia64 at least, not sure what else). Another one would be having CLKDEV_LOOKUP without COMMON_CLK. This one is not a problem for m68k but is for a couple of ARM and MIPS platforms that have not yet been converted to COMMON_CLK. There are probably a couple more like this. I don't actually see any that are /only/ used by m68k, but there are some interfaces that would be good to stop using overall to keep things simpler. Arnd
Re: m68k using deprecated internal APIs?
On 10/27/18 5:01 PM, Geert Uytterhoeven wrote: >> This kind of approach has worked well in the Debian community > > Right, Debian stopped supporting m68k a long time ago ;-) This stuff is so getting annoying. I don't understand why all of a sudden there is such a big urge to kick everything out that is old. Is the Linux kernel supposed to be an x86-only project? I don't get it. The port is actively maintained and working well, new drivers are being added. And there is a vibrant community using it. Try buying a used Amiga on eBay and you know what I mean. There is new hardware being developed all the time. Just recently, we added support for the xsurf100 network card from Individual Computers. And I expect more drivers to be added in the future. Is Linux really only a commercial product now so that everything that is not maintained by a large company needs to go quick? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
m68k using deprecated internal APIs?
Hi Arnd,
https://lwn.net/Articles/769468/ wrote:
> For example, the m68k architecture uses a number of internal APIs that no
> other
> architecture needs at this point; removing that architecture would enable
> removing
> the APIs as well
and
> Ted Ts'o suggested that an ultimatum could be made: either the m68k
> architecture
> stops using the old, deprecated timer API (for example) within one year or it
> is
> removed from the kernel.
Which APIs are these exactly?
> This kind of approach has worked well in the Debian community
Right, Debian stopped supporting m68k a long time ago ;-)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 0/4] m68k: system call table generation support
Hi Firoz,
On Fri, Oct 26, 2018 at 7:06 AM Firoz Khan wrote:
> The purpose of this patch series is, we can easily add/modify/delete
> system call table support by changing entry in syscall.tbl file
> instead of manually changing many files. The other goal is to unify
> the system call table generation support implementation across all
> the architectures.
>
> The system call tables are in different format in all architecture.
> It will be difficult to manually add, modify or delete the system
> calls in the respective files manually. To make it easy by keeping
> a script and which'll generate uapi header file and syscall table
> file.
>
> syscall.tbl contains the list of available system calls along with
> system call number and corresponding entry point. Add a new system
> call in this architecture will be possible by adding new entry in
> the syscall.tbl file.
>
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
>
> ARM, s390 and x86 architecuture does exist the similar support. I
> leverage their implementation to come up with a generic solution.
>
> I have done the same support for work for alpha, ia64, microblaze,
> mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
> repository contains more details.
> Git repo:- https://github.com/frzkhn/system_call_table_generator/
>
> Finally, this is the ground work to solve the Y2038 issue. We need
> to add two dozen of system calls to solve Y2038 issue. So this patch
> series will help to add new system calls easily by adding new entry
> in the syscall.tbl.
Thanks for the update!
Can you please tell the audience what has been changed in v4?
When posting a new version of a patch or patch series, it is a good
idea to include a changelog in the cover letter and/or patches.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
