Re: Things not referenced in kernel configs, but mentioned in files.*
On Nov 13, 7:33am, Jason Thorpe wrote: } > On Nov 13, 2018, at 7:15 AM, John Nemeth wrote: } > } > That's a different kind of unusable. :-) That puts it in } > the same camp as strip, where there may be functioning hardware, } > but you can't do anything with the hardware. } } ...and when you can't do anything with the hardware, people don't use } (i.e. "test by dogfooding") the drivers, which leads to bit rot and } maintenance headaches. As I noted, it's not quite the same. Assuming that our ISDN stack was capable of acting as "network" side, you could have used it in a back-to-back configuration. Granted, that's probably not very interesting except for special circumstances. It's my understanding, which may be incorrect, that strip required a central node, and without that you couldn't do anything. }-- End of excerpt from Jason Thorpe
Re: Things not referenced in kernel configs, but mentioned in files.*
> On Nov 13, 2018, at 7:15 AM, John Nemeth wrote: > > That's a different kind of unusable. :-) That puts it in > the same camp as strip, where there may be functioning hardware, > but you can't do anything with the hardware. ...and when you can't do anything with the hardware, people don't use (i.e. "test by dogfooding") the drivers, which leads to bit rot and maintenance headaches. -- thorpej
Re: Things not referenced in kernel configs, but mentioned in files.*
On Nov 13, 7:10am, Martin Husemann wrote: } On Mon, Nov 12, 2018 at 05:18:41PM -0800, John Nemeth wrote: } > Was the ISDN code usable? Something in the back of my mind is telling } > me that it wasn't and thus was just clutter. } } It was usable, but even here it is hard (impossible?) to get real ISDN } land lines nowadays. That's a different kind of unusable. :-) That puts it in the same camp as strip, where there may be functioning hardware, but you can't do anything with the hardware. Granted you could setup private connections if you wish (I once put a PRI card in a Linux box and made it network side for testing purposes). On a side note, ISDN land lines are very common here in the form of PRI used for trunking purposes. There would be some use for that when coupled with Asterisk (or another soft PBX) to create a phone system. However, for that, we would need DAHDI which we don't currently have. DAHDI is somewhat on my radar, but given that you can do pretty much everything by talking SIP to an external box it isn't my highest priority. If somebody else wishes to port DAHDI that would be great! }-- End of excerpt from Martin Husemann
Re: Things not referenced in kernel configs, but mentioned in files.*
On Tue, Nov 13, 2018 at 1:26 AM Christos Zoulas wrote: > > In article , > Greg Troxel wrote: > > > >co...@sdf.org writes: > > > >> This is an automatically generated list with some hand touchups, feel > >> free to do whatever with it. I only generated the output. > >> > >> ac100ic > >> acemidi > >> acpipmtr > >> [snip] > > > >I wonder if these are candidates to add to an ALL kernel, and if it will > >turn out that they are mostly not x86 things. > > > >I see we only have ALL for i386/amd64. I wonder if it makes sense to > >have one in evbarm. > > We should. And we should build kernels of ALL configs in daily builds... ozaki-r
Re: Things not referenced in kernel configs, but mentioned in files.*
On Mon, Nov 12, 2018 at 05:18:41PM -0800, John Nemeth wrote: > Was the ISDN code usable? Something in the back of my mind is telling > me that it wasn't and thus was just clutter. It was usable, but even here it is hard (impossible?) to get real ISDN land lines nowadays. Martin
Re: Things not referenced in kernel configs, but mentioned in files.*
On Mon, Nov 12, 2018 at 2:07 PM John Nemeth wrote: > On Nov 12, 1:16pm, Jason Thorpe wrote: > } Subject: Re: Things not referenced in kernel configs, but mentioned in > fil > } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > } > > } > wbsio and wt also seems to fit in that category. > } > } Isn't "wt" an ancient PC tape drive? We should make an effort > > Yes. > > } to prune more deadwood drivers. > > How do we know that it's deadwood? How do we know somebody > out there doesn't still have functioning hardware? I will grant > you that in this case, it is unlikely as those things were total > junk. But, still... Deprecate, maybe developing a formal deprecation method if there’s not one already? Like how it’s logged, how many releases/months of grace, ... -bch > > }-- End of excerpt from Jason Thorpe >
Re: Things not referenced in kernel configs, but mentioned in files.*
On Nov 12, 2:12pm, Jason Thorpe wrote: } > On Nov 12, 2018, at 1:59 PM, John Nemeth wrote: } > } On Nov 12, 1:16pm, Jason Thorpe wrote: } > } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: } > } > } > } > wbsio and wt also seems to fit in that category. } > } } > } Isn't "wt" an ancient PC tape drive? We should make an effort } > } > Yes. } > } > } to prune more deadwood drivers. } > } > How do we know that it's deadwood? How do we know somebody } > out there doesn't still have functioning hardware? I will grant } > you that in this case, it is unlikely as those things were total } > junk. But, still... } } We managed to do it w/ the ISDN code. I suggest we put together } a list, post it to netbsd-announce, and note that there's always } the Attic. Was the ISDN code usable? Something in the back of my mind is telling me that it wasn't and thus was just clutter. }-- End of excerpt from Jason Thorpe
Re: Things not referenced in kernel configs, but mentioned in files.*
> On Nov 12, 2018, at 1:59 PM, John Nemeth wrote: > > On Nov 12, 1:16pm, Jason Thorpe wrote: > } Subject: Re: Things not referenced in kernel configs, but mentioned in fil > } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > } > > } > wbsio and wt also seems to fit in that category. > } > } Isn't "wt" an ancient PC tape drive? We should make an effort > > Yes. > > } to prune more deadwood drivers. > > How do we know that it's deadwood? How do we know somebody > out there doesn't still have functioning hardware? I will grant > you that in this case, it is unlikely as those things were total > junk. But, still... We managed to do it w/ the ISDN code. I suggest we put together a list, post it to netbsd-announce, and note that there's always the Attic. -- thorpej
Re: Things not referenced in kernel configs, but mentioned in files.*
FWIW, it's not a great idea to throw all of the i2c drivers into a kernel what will ever be booted, because of the i2c address assignment situation. > On Nov 12, 2018, at 2:15 PM, Brad Spencer wrote: > > > co...@sdf.org writes: > >> This is an automatically generated list with some hand touchups, feel >> free to do whatever with it. I only generated the output. >> > > Random ramblings below... > > [snip] > >> am2315temp > > The am2315 will, in theory, work on any reasonable i2c bus, but has only > been tested on a RPIish sort of thing. > > [snip] > >> gpioirq >> gpiopps > > The gpioirq and gpiopps drivers should function with any system with > gpio(4) support. But again, only tested on the RPI. > > [snip] > >> si70xxtemp > > The si70xx will also, in theory, work on any fairly well behaved i2c > bus. In particular, you need to be able a zero length read cycle... or > we need to implement the ability to perform clock stretching on the i2c > bus. Only tested and messed with on a RPI. > > > Maybe support will appear some day for one of the USB to i2c chips that > exist in the world... [hint: there is one on Adafruit that is FTDI > based and fully documented], and it will be more obvious how the above > would be useful on more than the RPI. > > I don't know where it leaves these with respect to a ALL sort of config > file. Nothing should really be harmed by including any of them in such > a file. > > > > > -- > Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org -- thorpej
Re: Things not referenced in kernel configs, but mentioned in files.*
> there's always the Attic
I'm currently using a custom kernel with a driver from netbsd-8
(nouveau), it was surprisingly painless to put the old version in.
(in case anyone is curious, copy sys/external/bsd/{common,drm2}. Of
course, I should attempt to fix it, but I like to be able to run
-current until we figure it out).
Re: Things not referenced in kernel configs, but mentioned in files.*
co...@sdf.org writes: > This is an automatically generated list with some hand touchups, feel > free to do whatever with it. I only generated the output. > Random ramblings below... [snip] > am2315temp The am2315 will, in theory, work on any reasonable i2c bus, but has only been tested on a RPIish sort of thing. [snip] > gpioirq > gpiopps The gpioirq and gpiopps drivers should function with any system with gpio(4) support. But again, only tested on the RPI. [snip] > si70xxtemp The si70xx will also, in theory, work on any fairly well behaved i2c bus. In particular, you need to be able a zero length read cycle... or we need to implement the ability to perform clock stretching on the i2c bus. Only tested and messed with on a RPI. Maybe support will appear some day for one of the USB to i2c chips that exist in the world... [hint: there is one on Adafruit that is FTDI based and fully documented], and it will be more obvious how the above would be useful on more than the RPI. I don't know where it leaves these with respect to a ALL sort of config file. Nothing should really be harmed by including any of them in such a file. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Things not referenced in kernel configs, but mentioned in files.*
On Nov 12, 1:16pm, Jason Thorpe wrote: } Subject: Re: Things not referenced in kernel configs, but mentioned in fil } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: } > } > wbsio and wt also seems to fit in that category. } } Isn't "wt" an ancient PC tape drive? We should make an effort Yes. } to prune more deadwood drivers. How do we know that it's deadwood? How do we know somebody out there doesn't still have functioning hardware? I will grant you that in this case, it is unlikely as those things were total junk. But, still... }-- End of excerpt from Jason Thorpe
Re: Things not referenced in kernel configs, but mentioned in files.*
> On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > > wbsio and wt also seems to fit in that category. Isn't "wt" an ancient PC tape drive? We should make an effort to prune more deadwood drivers. -- thorpej
Re: Things not referenced in kernel configs, but mentioned in files.*
On Nov 12, 3:38pm, co...@sdf.org wrote:
} On Mon, Nov 12, 2018 at 10:23:26AM -0500, Greg Troxel wrote:
} > co...@sdf.org writes:
} >
} > > This is an automatically generated list with some hand touchups, feel
} > > free to do whatever with it. I only generated the output.
} > >
} > > ac100ic
} > > acemidi
} > > acpipmtr
} > > [snip]
} >
} > I wonder if these are candidates to add to an ALL kernel, and if it will
} > turn out that they are mostly not x86 things.
} >
} > I see we only have ALL for i386/amd64. I wonder if it makes sense to
} > have one in evbarm.
}
} The actual search was roughly (and I didn't re-test these commands)
} find src/sys -name 'files.*' | xargs grep 'attach' | awk '{print $2}' >
drivers
} for i in `cat drivers`; do echo $i; grep "^$i[^a-z]" src/sys/arch/*/conf/*;
done |grep -v ALL > appearances-in-configs
} grep -B 1 '[^0-9]0$' appearances-in-configs > no-appearance-in-configs
}
}
} And some manual removal of things that are obviously not drivers,
} removing duplicates, sorting...
}
} So, I am excluding things that appear in ALL, and I am not checking if
} they appear as modules.
}
} So far I had complaints about the appearance of 'lm' which cannot be
} safely included in a default kernel, for example.
wbsio and wt also seems to fit in that category. Maybe change
the regex to "^#?$i[^a-z]" to catch commented out things. Of
course, the flip side is that things that are commented out are
naturally going to get less testing.
}-- End of excerpt from co...@sdf.org
Re: Things not referenced in kernel configs, but mentioned in files.*
co...@sdf.org wrote: >This is an automatically generated list with some hand touchups, feel >free to do whatever with it. I only generated the output. Maybe we could put your list somewhere under src/doc, src/doc/ORPHANS ? Then delete lines as we add them to one or other of the ALL configs.
Re: Things not referenced in kernel configs, but mentioned in files.*
Hello, On Mon, 12 Nov 2018 01:45:58 + co...@sdf.org wrote: > This is an automatically generated list with some hand touchups, feel > free to do whatever with it. I only generated the output. A good chunk of them are probably work in (various stages of) progress. Like ... > vac ... which was supposed to become my gdium audio driver at some point. have fun Michael
Re: Things not referenced in kernel configs, but mentioned in files.*
In article , Greg Troxel wrote: > >co...@sdf.org writes: > >> This is an automatically generated list with some hand touchups, feel >> free to do whatever with it. I only generated the output. >> >> ac100ic >> acemidi >> acpipmtr >> [snip] > >I wonder if these are candidates to add to an ALL kernel, and if it will >turn out that they are mostly not x86 things. > >I see we only have ALL for i386/amd64. I wonder if it makes sense to >have one in evbarm. We should. christos
Re: Things not referenced in kernel configs, but mentioned in files.*
co...@sdf.org writes: > So, I am excluding things that appear in ALL, and I am not checking if But ALL is an x86 thing, currently. > they appear as modules. Interesting, but I suppose they then belong in ALL also. > So far I had complaints about the appearance of 'lm' which cannot be > safely included in a default kernel, for example. Sure, lots of things are not ok in GENERIC, but do those concerns apply to it being in ALL?
Re: Things not referenced in kernel configs, but mentioned in files.*
On Mon, Nov 12, 2018 at 10:23:26AM -0500, Greg Troxel wrote:
>
> co...@sdf.org writes:
>
> > This is an automatically generated list with some hand touchups, feel
> > free to do whatever with it. I only generated the output.
> >
> > ac100ic
> > acemidi
> > acpipmtr
> > [snip]
>
> I wonder if these are candidates to add to an ALL kernel, and if it will
> turn out that they are mostly not x86 things.
>
> I see we only have ALL for i386/amd64. I wonder if it makes sense to
> have one in evbarm.
The actual search was roughly (and I didn't re-test these commands)
find src/sys -name 'files.*' | xargs grep 'attach' | awk '{print $2}' > drivers
for i in `cat drivers`; do echo $i; grep "^$i[^a-z]" src/sys/arch/*/conf/*;
done |grep -v ALL > appearances-in-configs
grep -B 1 '[^0-9]0$' appearances-in-configs > no-appearance-in-configs
And some manual removal of things that are obviously not drivers,
removing duplicates, sorting...
So, I am excluding things that appear in ALL, and I am not checking if
they appear as modules.
So far I had complaints about the appearance of 'lm' which cannot be
safely included in a default kernel, for example.
Re: Things not referenced in kernel configs, but mentioned in files.*
co...@sdf.org writes: > This is an automatically generated list with some hand touchups, feel > free to do whatever with it. I only generated the output. > > ac100ic > acemidi > acpipmtr > [snip] I wonder if these are candidates to add to an ALL kernel, and if it will turn out that they are mostly not x86 things. I see we only have ALL for i386/amd64. I wonder if it makes sense to have one in evbarm.
