hello justin !
i have just tried to install the latest 2.4.3pre3 kernel with your
driver.
it failed with yacc: file not found.
while i could install yacc, i have never had to use it before. i was
assuming that the newer bison could do the same thing (which is what
i have installed).
so far, the kernel has not relied on yacc, which is why i'd like to
ask you if it's possible to make it work with bison.
sorry if this has been dealt with before, but i didn't find anything
in the lkml archive.
regards,
j?rn
please keep me cc:ed, i'm not on lkml. thanks.
--
J?rn Nettingsmeier
home://Kurf?rstenstr.49.45138.Essen.Germany
phone://+49.201.491621
http://www.folkwang-hochschule.de/~nettings/
>hello justin !
>
>i have just tried to install the latest 2.4.3pre3 kernel with your
>driver.
>it failed with yacc: file not found.
>while i could install yacc, i have never had to use it before. i was
>assuming that the newer bison could do the same thing (which is what
>i have installed).
>so far, the kernel has not relied on yacc, which is why i'd like to
>ask you if it's possible to make it work with bison.
The assembler makefile doesn't reference yacc, but instead relies
on gmake's built in rules to figure out how to generate a .c from
a .y. I'm somewhat surprised that bison doesn't create a link to
yacc or that gmake doesn't try to look for bison.
Oh well. We'll just have to be more careful in how future patches
are generated so that the dependency between the generated firmware
files and the firmware source only triggers if you are actually
performing firmware development. Trying to build this simple
assmebler on everyone's systems is turning out to be just too
hard.
--
Justin
In article <[email protected]> you wrote:
> The assembler makefile doesn't reference yacc, but instead relies
> on gmake's built in rules to figure out how to generate a .c from
> a .y. I'm somewhat surprised that bison doesn't create a link to
> yacc or that gmake doesn't try to look for bison.
Yepp, gmake is kindof stupid in that respect - it does also not try
to use flex if there is no lex, etc... I'd really vote for a BSDish
sys.mk.
> Oh well. We'll just have to be more careful in how future patches
> are generated so that the dependency between the generated firmware
> files and the firmware source only triggers if you are actually
> performing firmware development. Trying to build this simple
> assmebler on everyone's systems is turning out to be just too
> hard.
What about simply removing the firmware source and assembler from the
kernel tree? We have lots of firmware in the kernel tree for which
there isn't even firmware avaible...
The few people that want to do firware development could download it
from your ftp site.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
>What about simply removing the firmware source and assembler from the
>kernel tree? We have lots of firmware in the kernel tree for which
>there isn't even firmware avaible...
What, and not allow others to fix my bugs for me? :-)
Lots of people have embedded this driver just because it is completely
open source. I'd like to have all distributions be "complete"
distributions.
--
Justin
"Justin T. Gibbs" wrote:
>
> >hello justin !
> >
> >i have just tried to install the latest 2.4.3pre3 kernel with your
> >driver.
> >it failed with yacc: file not found.
> >while i could install yacc, i have never had to use it before. i was
> >assuming that the newer bison could do the same thing (which is what
> >i have installed).
> >so far, the kernel has not relied on yacc, which is why i'd like to
> >ask you if it's possible to make it work with bison.
>
> The assembler makefile doesn't reference yacc, but instead relies
> on gmake's built in rules to figure out how to generate a .c from
> a .y. I'm somewhat surprised that bison doesn't create a link to
> yacc or that gmake doesn't try to look for bison.
>
> Oh well. We'll just have to be more careful in how future patches
> are generated so that the dependency between the generated firmware
> files and the firmware source only triggers if you are actually
> performing firmware development. Trying to build this simple
> assmebler on everyone's systems is turning out to be just too
> hard.
i might also be SuSE 7.1 related, since this was the first kernel i
compiled on the new distro.
but since the problem arose only with the new aic driver, i thought
it might be that you had a slightly different development
environment...?
anyway, robbert muller sent me the following simple workaround:
<quote>
Just create a shell script called yacc with the following content
-------------------
#!/bin/sh
bison --yacc $*
-------------------
i ran into the same problem with a school proiject here yesterday
</quote>
regards,
j?rn
--
J?rn Nettingsmeier
home://Kurf?rstenstr.49.45138.Essen.Germany
phone://+49.201.491621
http://www.folkwang-hochschule.de/~nettings/
On Wed, 7 Mar 2001, Justin T. Gibbs wrote:
> >What about simply removing the firmware source and assembler from the
> >kernel tree? We have lots of firmware in the kernel tree for which
> >there isn't even firmware avaible...
>
> What, and not allow others to fix my bugs for me? :-)
>
> Lots of people have embedded this driver just because it is completely
> open source. I'd like to have all distributions be "complete"
> distributions.
>
> --
> Justin
alias yacc='bison -y'
If you don't have one of these, you don't have the tools necessary
to do kernel development.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Wed, Mar 07, 2001 at 08:29:45AM -0700, Justin T. Gibbs wrote:
> >What about simply removing the firmware source and assembler from the
> >kernel tree? We have lots of firmware in the kernel tree for which
> >there isn't even firmware avaible...
>
> What, and not allow others to fix my bugs for me? :-)
>
> Lots of people have embedded this driver just because it is completely
> open source. I'd like to have all distributions be "complete"
> distributions.
I presume the aicasm (or whatever) can do its meager DB needs
by simpler ubiquitous things like GDBM. SleepyCat DBx is good,
but in this case as serious overkill as e.g. using Oracle ;)
(No, I didn't read the source of the aicasm.)
There really should be some convenient way to compile the firmware
from source when wanted, but the normal case should not be dependent
of FIRMWARE SOURCE - the integer/byte array include file should
be enough for normal users.
$ (cd drivers/xx/yy; make aic7xxx.fw )
What HOSTCC et.al. settings are needed, that I can't say,
and that 'make' method doesn't get top-level definitions in...
Simultaneously (as 'aic7xxx.fw' would not be the real filename),
aic7xxx.o file's dependencies would contain the real firmware
files so that "make bzImage" will recompile it correctly.
When people like Justin are sending the driver update to Linus,
they just need to be carefull at sending all relevant files/diffs.
We are placing a lot of trust to these firmware makers to supply
us working firmware, why not trust them to do it right so that
compiling kernel won't need to generate firmware assembler program
at first...
> --
> Justin
/Matti Aarnio
On Wed, Mar 07, 2001 at 08:29:45AM -0700, Justin T. Gibbs wrote:
> >What about simply removing the firmware source and assembler from the
> >kernel tree? We have lots of firmware in the kernel tree for which
> >there isn't even firmware avaible...
>
> What, and not allow others to fix my bugs for me? :-)
>
> Lots of people have embedded this driver just because it is completely
> open source. I'd like to have all distributions be "complete"
> distributions.
Not having it in the kernel tree doesn't have to mean not having it in
the distributions. If you are really concerned having iy in the kernel
tree it might also be a good idea to have it in scripts.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
> I presume the aicasm (or whatever) can do its meager DB needs
> by simpler ubiquitous things like GDBM. SleepyCat DBx is good,
> but in this case as serious overkill as e.g. using Oracle ;)
> (No, I didn't read the source of the aicasm.)
People keep saying stuff like this. I think one of the best things
a developer can realize is that being lazy is often a good thing. I
already was experience with using db, it took me about 5 minutes to
utilize it for this project when rolling my own would have taken
much longer, and it happens to be available on almost any platform
of interest (including windows which is used to host some of the RTOS
environments that also use this driver). More importantly, it works...
so why fix it?
People who really want to assemble the firmware will install the required
packages. We'll just ship precompiled firmware and make sure the dependencies
don't fire even if only a few of the files in the dependency chain are
updated.
--
Justin
[J?rn Nettingsmeier, quoting Robert Muller]
> Just create a shell script called yacc with the following content
> -------------------
> #!/bin/sh
> bison --yacc $*
> -------------------
> i ran into the same problem with a school proiject here yesterday
Why does nobody learn shell anymore? (Just curious.)
#!/bin/sh
exec bison -y "$@"
Peter