Linux Kernel contains only C code?

[Daniel.]

I'm just curious. What problems in kernel involves parsing?

On Feb 2, 2018 5:01 AM, <valdis.kletnieks at vt.edu> wrote:

> On Thu, 01 Feb 2018 11:37:26 -0500, Aruna Hewapathirane said:
>
> > Somethings are not so obvious like what could possibly be a *.y file or
> > *.tc file ? If you type in find -name "*.y" in my case i see:
> >
> > aruna at debian:~/linux-4.15$ find -name "*.y"
>
> > Now if I pass that to the 'file' command ...
> >
> > aruna at debian:~/linux-4.15$ file `find -name "*.y"` // yes you need those
> > back ticks :)
> >
> > ./drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y: C source, ASCII text
>
> > So 'file' tells us these are C program files ? Lets verify ? If you 'cat'
> > any of these files you will see it is actual C code. Why does it have a
> > file extension of .y ?
>
> Actually, if you look more closely at it, it's *not* actually C code.  The
> 'file'
> command makes its best guess, triggered off things like '#include', etc.
>
> The 'tl;dr' answer is "The *.y are input files for bison, and the *.l are
> input files for flex".
>
> The more detailed explanation, with 50 years of computer history....
>
> [/usr/src/linux-next] head -20 tools/perf/util/expr.y
> /* Simple expression parser */
> %{
> #include "util.h"
> #include "util/debug.h"
> #define IN_EXPR_Y 1
> #include "expr.h"
> #include "smt.h"
> #include <string.h>
>
> #define MAXIDLEN 256
> %}
>
> %pure-parser
> %parse-param { double *final_val }
> %parse-param { struct parse_ctx *ctx }
> %parse-param { const char **pp }
> %lex-param { const char **pp }
>
> %union {
>         double num;
>
> That's got a bunch of % in unusual places for C, doesn't it? :)
>
> Let's hit the rewind button back 5 decades or so, when tools for building
> programs were just becoming created.  And everybody who wanted to write a
> compiler for a language, or parsing data that wasn't strict 'ID is in
> columns
> 5-12' formatting, or a whole bunch of other stuff, had to write a parser
> to do
> the parsing.
>
> For those who have never done it, writing lexical scanners and parsers by
> hand
> is a thankless job. I know from experience that the parse table for an LALR
> parser for Pascal ends up being essentially a spreadsheet with some 300
> rows
> and 400 columns that you get to fill in by hand one at a time - and
> getting one
> entry wrong means you have a buggy compiler (I took Compiler Design in
> college
> the last year we had to do it by hand)
>
> The first few compiled languages (COBOL, FORTRAN, and a few others) also
> had to
> make do with hand-coded parsers.  And then in 1958, Algol happened, and it
> spawned all sorts of languages - everything from C to PL/I to Pascal and
> probably 200+ others (pretty much every language that allows nested
> declarations and has begin/end tokens of some sort owes it to Algol).  And
> the
> other thing about Algol was that it was a much "bigger" language than
> previous
> ones, so John Backus invented a meta-language called BNF to provide a
> formal
> specification of the syntax.
>
> (For those who are curious, a EBNF specification for Pascal syntax is here:
> http://www.fit.vutbr.cz/study/courses/APR/public/ebnf.html
>
> The interesting thing about BNF is that it has these things called
> "production
> rules" which define what legal programs look like - and the test for
> "legal"
> can be done with a parser using a software/mathematical construct called a
> "finite state machine" (and the 3 of you who understand the difference
> between
> a context-sensitive grammar and a context-free grammar can stop giggling
> right
> now.. ;)
>
> So somebody had the bright idea that if you had a formal BNF
> specification, you
> could write a program that would read the BNF, and spit out the C source
> for a
> parser skeleton based on a finite state machine.  And thus were born two
> programs called 'lex' (a lexical scanner - something that reads the
> source, and
> outputs code that says "Hey, that's the word 'struct'" or "we just saw a
> 'for"). and another called 'yacc' (Yet Another Compiler Compiler) which
> did the
> higher level "this is a legal function, but *that* right there is a
> messed-up
> 'if' statement that has a syntax error" stuff.  Oh, and generate output
> code, too.
>
> Of course, that was decades ago, and eventually somebody wrote a faster
> 'lex' -
> and thus was born /usr/bin/flex.  And yacc needed work, so the improved
> version
> was, of course, called bison (think about it for a bit..)
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180202/692d68c5/attachment-0001.html>