Ioctl material is quite confused, indeed. Some requests are related to
the device, and some are related to the line discipline. I'll try to
summarize things for the 1.0 and the 1.1.7x kernels and anything that
happened in between.
The 1.1.7x series features the following approach: <#2704#> tty_ioctl.c<#2704#>
implements only line discipline requests (namely <#2705#>
n_tty_ioctl()<#2705#>, which is the only n_tty function outside of <#2706#>
n_tty.c<#2706#>), while the <#2707#> file_operations<#2707#> field points to <#2708#>
tty_ioctl()<#2708#> in <#2709#> tty_io.c<#2709#>. If the request number is not
resolved by <#2710#> tty_ioctl()<#2710#>, it is passed along to <#2711#>
tty-;SPM_gt;driver.ioctl<#2711#> or, if it fails, to <#2712#>
tty-;SPM_gt;ldisc.ioctl<#2712#>. Driver-related stuff for the console it to be found
in <#2713#> vt.c<#2713#>, while line discipline material is in <#2714#> tty_ioctl.c<#2714#>.
In the 1.0 kernel, <#2715#> tty_ioctl()<#2715#> is in <#2716#> tty_ioctl.c<#2716#> and
is pointed to by generic tty <#2717#> file_operations<#2717#>. Unresolved requests
are passed along to the specific ioctl function or to the line-discipline code,
in a way similar to 1.1.7x.
Note that in both cases, the <#2718#> TIOCLINUX<#2718#> request is in the
device-independent code. This implies that the console selection can
be set by <#2719#> ioctl<#2719#>ling any tty (<#2720#> set_selection()<#2720#> always operates
on the foreground console), and this is a security hole. It is also a good
reason to switch to a newer kernel, where the problem is fixed by
only allowing the superuser to handle the selection.
%
A variety of requests can be issued to the console device, and the
best way to know about them is to browse the source file <#2721#> vt.c<#2721#>.
%
%
%