-
Notifications
You must be signed in to change notification settings - Fork 0
/
design.txt
187 lines (157 loc) · 7.15 KB
/
design.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
## Use case
We want to know the DSDT and SSDT tables from our users so we can create an
application that automatically detects the right ACPI calls for disabling the
nvidia graphics card. Machine information from `dmidecode` must be attached too
so we know from which manufacturer and model the tables are from. To know which
video card is used, information about PCI devices should be attached too
## Current practices
These tables are available from the dump from the `acpidump` tool. Then,
`acpixtract` extracts the SSDT and DSDT tables from the previous dump which can
be converted to human-readable ASL using `iasl`. PCI device information is not
attached at all.
Until now, the user would have to:
1. install `acpidump` and `iasl`
2. Run `acpidump`, `acpixtract` and `iasl` to generate the human-readable ASL
files (*.dsl)
3. Run `dmidecode` several times for the manufacturer and model info
4. Create a tarball of the generated files (*.dsl and dmidecode.txt)
5. Send the result to an emailaddress or mailing list
## Comments
Currently, the submission of the dsl files are scattered and the information
often incomplete (missing machine information). Known places to find the ASL
files are the mailing list of Launchpad Hybrid Graphics, the ACPI wiki page of
Bumblebee-Project/Bumblebee and mailboxes of several developers. This makes it
hard to get to the actual task: analysing the files.
Furthermore, the current commands may be too complicated for the user, which
may lead to errors in running the right command.
## Goal
The commands for the user should be as easy as possible and the submission less
difficult, meaning that sending a mail may be too difficult since it involves
opening the mail client, selecting the tarball as attachment and press "Send".
For developers and other interested people, the next features should be
available:
- Search by machine information
- Download each individual DSDT or SSDT table
- Get a listing of submissions for each manufacturer, subdivided by product
names
- Search through the headers of the ASL files (OEM ID, OEM Table ID)
## Implementation
The centralized place is a webserver which accepts uploads of dmidecode and
acpidump data and compile the tables itself. This has the advantage that:
- the user does not have to install iasl anymore
- the `acpixtract` and `iasl` may be removed from the client commands
(simplification)
- should there be any errors in the `iasl` or `acpixtract` tools on the
client-side, the resulting ASL files may contain errors too. Generating the
files on the server side ensures that the generated files have a consistent
formatting.
- the receiver only needs to validate one file (acpidump.txt) instead of
several *.dsl files
## Workflow
On the user side:
1. The user installs acpidump
2. For the ACPI dump, (s)he runs `sudo acpidump > acpidump.txt`
3. Then (s)he writes the following dmidecode fields to `dmidecode.txt`:
- baseboard-manufacturer
- baseboard-product-name
- baseboard-version
- system-manufacturer
- system-product-name
- system-version
This can be done with:
: > dmidecode.txt
for keyword in baseboard-manufacturer baseboard-product-name \
baseboard-version system-manufacturer system-product-name \
system-version; do
printf "%-22s: %s\n" $keyword "$(sudo dmidecode -s $keyword)" \
>> dmidecode.txt
done
In other words, each line contains `keyword : value` (note the
padding between keyword and the colon)
3. Store the PCI device info: `lspci -n > lspci.txt`
4. The files should then be submitted to the server using wget or curl or using
a web interface
These steps should be available in a shellscript so the user does not have to
copy the command which may result in an error. Example usage:
wget example.com/acpi-info -O acpi-info && bash acpi-info
`-O acpi-info` is added explicitly to prevent existing files to be preserved.
On the server side:
1. The webserver validates the file size of `acpidump.txt` (1M should be
reasonable, my three tables creates a file of size 212K)
2. dmidecode information is validated, each field should be present and the
value should not exceed X characters (X=32?). Format is "%-22s: %s"
3. The checksum of `acpidump.txt` is checked. If it was not seen before, the
file is added to the acpixtract queue
4. lspci.txt is queued for processing / processed
5. The result (duplicate, success or error) is displayed
### lspci queue
The contents of lspci.txt is checked which should match:
"BusID DeviceClass: VendorID:DeviceID (rev NN)" where DeviceClass is a VGA
compatible controller or a 3D controller. VendorID is 8086 for Intel
Corporation and 10de for nVidia Corporation.
Example for a GT425M:
02:00.0 0300: 10de:0df0 (rev a1)
Only the BusID (02:00.0) is important to us, the device ID (0df0) should be
looked up.
### acpixtract queue
1. `acpixtract` is ran to get DSDT.dat and SSDT[1-9].dat files (SSDT is
optional but we need to set a sensible limit for number of SSDT tables)
2. The resulting .dat files are disassembled to .dsl (ASL) files using `iasl`
3. The .dsl files are validated
4. If everything is valid, the DSDT and SSDT tables are saved into a directory
is named to the checksum of acpidump.txt
5. The result of the commands are saved to a public log file
### Directory structure
/dump/SUM/ - listing of available tables
/dump/SUM/dsdt.dsl - dsdt table
/ssdt/SUM/SSDT*.dsl - ssdt table
/submission/NUMBER/index.html -> links to tables, txt's and display notes
/submission/NUMBER/lspci.txt
/submission/NUMBER/dmidecode.txt
Categories (need further thinking):
/board-manufacturer/
/board-product-name/
/board-version/
/sys-manufacturer/
/sys-product-name/
/sys-version/
Consider:
- linking to submissions
- dividing manufacturer into product names
- put this in a search form
### Database
machines (based on the acpidump.txt)
- 1:1 DSDT
- 1:N SSDT
- 1:1 notes (stored in separate database table)
submissions (N:1 with machines)
- 1:1 dmidecode.txt
- 1:1 lspci.txt
- 1:1 dmidecode.txt
- 1:1 metadata: submission date
notes (1:1 with machines)
Old notes gets removed by moderators
- notes (255 chars? personally, I don't think that it should be a long note
like a guide but something short like "rebranded BTO notebook, bto.eu")
- timestamp of change (timestamp in MySQL)
- some way to contact / identify the user (email? IP?)
Data which can be retrieved from files ("caching"):
- dmidecode
- 6 fields of 32 chars (should contain unique values)
- machine
- PCI Bus ID (7 chars)
- Vendor ID (2 bytes, smallint in MySQL)
- Device ID (2 bytes, smallint in MySQL)
- submissions
- timestamp (timestamp in MySQL, valid until 2038)
- notes (max 255 chars)
XXX to be filled
### Preventing abuse
Public services are always prone to abuse. There just needs to be one misbehaving idiot and we've another ton of mess to clean up. So, we must have some way to prevent abuse which include:
- spammers inserting random glibberish
- invalid acpidump.txt, dmidecode.txt or lspci.txt
- spam notes
Possible protections:
- moderated upload, each upload has to be marked as accepted
- reCAPTCHA for the notes
- Hope for the best and pray to God that evil people and machines do not exist