Seeing as the DOM should be seen as an IDE drive (if I'm not mistaken), I doubt that there would be any code in the IDE driver to determine whether the drive is write protected or not - as this isn't part of the IDE specification.
S >From: "S Mohan" <[EMAIL PROTECTED]> >To: "guitarlynn" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >Subject: [leaf-user] SST-DoM experiment >Date: Fri, 30 Aug 2002 15:55:54 +0530 > >Dear Mike/Lynn/Brad: > >I soldered a jumper on my SST DoM. I expected it to give me a mounted as >readonly filesystem message when it is mounted. It did not. I saved a file >to that fs by piping output of ls to a file. That also went thro'. I was >puzzled. I then tried an explicit sync - Module reported an error > >No DRQ after issuing write. >Status error status=0x51 (DriveReady SeekComplete error) >Status error status=0x04 (DriveStatusError) > >This make the drive read only but looks convoluted. Does it not? > >I removed the jumper and did a sync, it went thro' smoothly. > >I expected the system to report readonly at mount time like it does for >write-protect floppies. > >Any other experiences? > >Mohan >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of guitarlynn >Sent: 30 August 2002 10:37 >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Re: [leaf-user] Webbased configuration > > >combined reply to several posts and some ideas (at the bottom): > >On Thursday 29 August 2002 14:59, Charles Steinkuehler wrote: > > > to leaf-devel. Is anyone ready to work on and/or discuss any > > > sections of this??? > > > > I can commit to any updates/modifications to sh-httpd that may be > > required. I think it's possible to dramatically increase the CGI > > response of the existing sh-httpd when running CGI's, which would be > > a big help for a CGI driven admin interface. > >Great! I had JamesSturdevant send me his patched sh-httpd binary >since several of us had major problems applying the diff he had >posted. I can send it to you off-list. I haven't dug through it or done >a diff myself, but the POST function does work per my testing. > > > > I can also help with architure, debugging, and (hopefully) crafty > > solutions to difficult scripting problems, but I can't commit to > > writing a major chunk of code due to current time constraints > > (although this may change suddenly if the company I work for suddenly > > "craters" :-/ ). > >I understand, I have a little more time once I finish roofing my house >(within the weekend, I hope). I can distribute what testing code I have >presently, but the architecture will definately need the be the first >thing on the todo list. I have compiled the "su-wrapper" binary that >will solve the write permissions problems as well. > >I'm presently working with SF on fixing my CVS access, as SF has >blocked all SSH connections from my Desktop the last couple of days. >:-((( > >BTW, I hope everything is still maintaning for you on the work end! > > > > *WACKY THOUGHT* - If we use sh-httpd as the web-server, and > > shell-script CGI's, would there be any benifit to wrapping the whole > > thing into a unified structure? In other words, create a custom > > script-based CGI interface, rather than trying to match "standard" > > CGI...something like a shell-script version of PHP. It could > > probably be faster/smaller than sticking with a conventional > > web-server/CGI approach, but would be less portable to other web > > servers. Something to think about. > >I hate to break any portability, but it would be a serious consideration >being that Weblet would essentially be integrated and only LEAF >style OS's would likely use it. It would also be a space saver on the >floppy end. Good idea! > > > > *WACKY IDEA #2* > > I've been investigating forth, and will be working on a > > micro-controller based hygrometer project running forth on an Ateml > > AVR processor in the near future. I've been wanting access to a > > scripting language more powerful than shell-script on LEAF, and I > > think forth might fit the bill. It's possible to compile forth > > without *ANY* libc requirements, but with the ability to talk > > *DIRECTLY* to the kernel (so you could load libc and make calls to > > it, if you really wanted, and do pretty much anything you > > want...remember the irreplacable part of libc is essentially an > > interface between C programs and the kernel, the rest is just a bunch > > of standard routines to ma >ke programmer's lives a bit easier). > > That's a lot of power for an interpreter that would probably weigh in > > at 10K to 20K Bytes, with code that can potentially run at near > > optimized C speeds (ie *WAY* faster than shell-script)! > >Good idea, but I don't know if any of us except Charles and David D >are familiar with Forth. I think I wrote a "hello world!" program in >Forth around 15 years ago, but I haven't retained any more about >the language since then. It was a low-level language similar to >machine language if I remember right. :-) > > > I've wanted to code an initial bootstrap loader in forth for a while > > (something that would boot from CD/Floppy/whatever, and optionally > > swap out the kernel, allowing fancy boot-time configuration w/o > > having to re-burn a CD to set kernel options. The ability to make > > kernel calls from a script, w/o having any libc or /bin/sh > > dependencies is very cool for a boot-loader. I also think an > > available forth interpreter could potentially help the construction > > of a new packaging system as well as fancy CGI admin scripts. > >Maybe a few of us should spend some time and learn forth. >C is about as cryptic of a language as I've learned to interpret, >but it sounds as if LEAF could gain a lot by using it. > > >On Thursday 29 August 2002 15:44, Eric Wolzak wrote: > > I would propose to get something like webmin does. > > some routines for individual packages > > reading in variables combining them with package specific items > > and then into the engine throwing out a webpage /form > > after posting the option file is written out in standard > > option.textfile > >This is what I had in mind. Adding backup would be rather simple >as well. The largest sticky point I see at this time is reading >and over-writing the existing configuration files. An example would >be setting the internal interface network information.... many packages >need this information. It would simplify things to enter the >information in it's own file, then source the information to the >relevent file needing it. > > >On Thursday 29 August 2002 16:47, Erich Titl wrote: > > Hi Eric, Lynn, Charles > > > > Asking for permission to come aboard. > >Welcome aboard!!! > > >On Thursday 29 August 2002 18:11, Peter Robinson wrote: > > Hi there > > I have written a web based admin tool for LEAF based loosly on > > MOSQUITO. > > > > It is written in /bin/sh. > > > > I dont believe you need perl for this task > >That is interesting! I've gone through the Mosquito code and found >that it covers many of the bases. However, there were several >disadvantages to using any of it....like lack of CLI configuration >options. The use of Jscript for a PHP-type atmosphere is interesting. >It would be nice if you could elaborate on what you have done. >Which LEAF version did you use? What modifications to the >existing configuration files have you made to make it work? > >The thttpd and uncgi combination is great, however uncgi has >not worked with sh-httpd in my testing due to CGI path restrictions. >Uncgi uses /cgi-bin/uncgi/'cgi-script' to interpret a CGI file and >sh-httpd does not support the "/path/binary/option" format. Exactly >what kind of "su wrapper" are you using to overwrite existing >configuration files or are you running thttpd as 'root'? > >************************* >*New thoughts* > >Through my personal testing, though rather minimal, I've ideally >got an environment that includes: > >*sh-httpd- can use GET or POST form methods. Either works fine, >but GET has a 255 character line limit, POST doesn't and save a >couple of lines of code to interpret the form information. James S.'s >POST patch has worked in my testing. This is the smallest webserver >that effectively works in my testing. > >*su-wrapper- to overwrite any file owned by 'root' and safely run >sh-httpd as a non-priviledged user a suid binary must run. This >small binary can be configured for many files and under set binaries >and conditions...very easy to configure and I've compiled it w/o any >glibc restrictions. > >*To ease compatibility of many packages needing specific duplicate >information/variables, a break-up of certain conf files should be made >and a check for depending packages should be made within the web >module. The other option is building a new LEAF version that fits this >format (successor to Dachstein???). Internal network and DMZ information >would be excellent examples of possible problems. Modifying the existing >package database would not be a good option, unless we are going through >them anyway and following something along the lines of David D's Port >system. > >*The CGI scripts should only setup the environment and call executables. >If the actual executable is not integrated in CGI, a CLI configuration >script could use the same code and minimize the total codebase that >would need to be written. There are several of us that have already >written configuration code for existing LEAF variants, possibly some of >this code may be portable. > >*Variant Independence- How do we propose to write the code in a way >that will not cater to a specific LEAf variant? This answer could >possibly lead to variant developers porting their configuration files >and packages to using our framework. The other option would be to >start a new LEAF variant to accomadate this development and encourage >other variants to use it if they choose. > >*Language for Executable code- Jscript, C, Forth and other languages >could reduce the overall size of the operational configuration. Due to >my proposed framework, the actual CGI size wouldn't benefit from using >Jscript, but writing executables in compiled code could make a large >difference. Who is available to write in any of these languages? >I've written a little C/C++, but most of my experience has been >modifying existing code to work for my environment rather than writing >it from scratch. > >*Package framework- Should there be a "base.lrp", a "www.lrp" and >a "cli.lrp" to account for different installation preferences. How would >we institute adding modules to the package.... porting lrpkg or apkg >would be ideal and user-friendly. > >****************** >These questions pose the largest problems we're likely to run into with >this project and *should* be answered before they become a problem. >I believe the member resources are available to do this in a short >period of time, but a solid framework and direction will make or break >the project. All opinions, ideas, and suggestions are welcome and >encouraged! > >Thx again, >~Lynn >-- > >~Lynn Avants >aka Guitarlynn > >guitarlynn at users.sourceforge.net >http://leaf.sourceforge.net > >If linux isn't the answer, you've probably got the wrong question! > > >------------------------------------------------------- >This sf.net email is sponsored by: OSDN - Tired of that same old >cell phone? Get a new here for FREE! >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >------------------------------------------------------------------------ >leaf-user mailing list: [EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/leaf-user >SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html > > > >------------------------------------------------------- >This sf.net email is sponsored by: OSDN - Tired of that same old >cell phone? Get a new here for FREE! >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >------------------------------------------------------------------------ >leaf-user mailing list: [EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/leaf-user >SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
